Jak obejść ograniczenia czasu wykonania SSH

[markoni 0]

Próbuję zrobić backup dużego folderu (3.3GB) na home.pl

Dowiedziałem się od nich, że niestety mają jakieś ograniczenie czasu wykonania komendy TAR do tworzenia archiwów .tar.gz

Archiwizowanie dochodzi do jakiegoś momentu i potem wyrzuca komunikat:

 

tar: Cannot write: broken pipe

tar: Child died with signal 9

tar: Error is not recoverable: exiting now

 

Poradźcie coś.

Małe foldery pakują się bez problemów.

Edytowano Lipiec 8, 2016 przez markoni (zobacz historię edycji)

[Gość Spoofy]

Oni to zawsze mają ograniczenia.... począwszy od ilości zapytań mysql, kończywszy na takich właśnie pierdołach.... Widać z tego że sami są bardziej ograniczeni niż ich limity....

 

Jedyną, złotą radę jaką mogę Ci dać - uciekaj. Uciekaj i to jak najdalej. Jeżeli chcesz prawdziwy hosting z dostępem SSH, bez limitów w zaufanej, wieloletniej firmie, zapraszam na PW

Edytowano Lipiec 8, 2016 przez Spoofy (zobacz historię edycji)

[behemoth 230]

Trzeba zadzwonić do home i poprosić o zdjęcie limitu. Robią to przeważnie w godzinach nocnych, jednorazowo. Później zakładają limit.

[vorren 53]

Z drugiej strony trudniej o overselling i wszyscy na matce mają w miarę jednakowe warunki..

[Piotr GRD 608]

Ostatecznie...

Spróbowałbym stworzyć archiwum TAR nieskompresowane i ewentualnie w kolejnej komendzie je skompresować do pobrania. Jeśli to nie przejdzie dla 3GB, to szkoda gadać... Wiem, że Home to przerost formy (ceny - regularnej, nie-promocyjnej) nad treścią, ale bez przesady... Mogliby przynajmniej NA STAŁE, CO NOC w określonych godzinach wyłączać limit i w jakimś FAQ dać wytyczne co do ustawiania cronjob w tych właśnie godzinach dla takich celów.

 

Jeśli powyższe nie wyjdzie i inaczej się nie da, to jest jeszcze opcja najpierw zrobienia listy wszystkich plików do skompresowania, podzielenie tego na części, a później tworzenie archiwum krok po kroku dodając kolejną partię plików. Nie mam dużego doświadczenia w korzystaniu z Unixa, więc nie będę tu próbował podawania gotowych komend, ale pewnie ls z odpowiednimi argumentami da listę plików, którą "po rurce" zapisać do pliku, potem listę jakoś podzielić, a następnie tar z argumentem -T oraz -r, żeby kolejne partie plików dodawać do tego samego archiwum.

Edytowano Lipiec 8, 2016 przez Piotr GRD (zobacz historię edycji)

[behemoth 230]

Tar tez jest ubijany.

[Vasthi 74]

Przesłać przez rsync na serwerze w Tiktalik za 9 zł (rozliczany godzinowo) i tam zrobić tara :]

[behemoth 230]

Rsynca też ubijają

[Pan Kot 1535]

Więc się z firmy ucieka w podskokach a nie szuka workaroundów na problemy, które w innych firmach nie istnieją.

[kafi 2425]

Rsynca też ubijają

 

Ale rsync możesz odpalić w pętli i "kiedyś-tam" się całość skopiuje .

 

 

Więc się z firmy ucieka w podskokach a nie szuka workaroundów na problemy, które w innych firmach nie istnieją.

 

Każdy kij ma dwa końce. Bo patrząc z drugiej strony, to masz jakieś tam środowisko, które działa dosyć przewidywalnie i trudniej o sytuację, że (odchodząc zupełnie od autora tematu) "moja" strona masakrycznie zwolni (a ja nic nie zmieniałem), bo "sąsiadowi" zachce się w tarować swoje zbiory. I weź tu debuguj, czy to sprawa przycięć w aplikacji, czy otoczenia...

[Pan Kot 1535]

masz jakieś tam środowisko, które działa dosyć przewidywalnie i trudniej o sytuację, że (odchodząc zupełnie od autora tematu) "moja" strona masakrycznie zwolni (a ja nic nie zmieniałem), bo "sąsiadowi" zachce się w tarować swoje zbiory. I weź tu debuguj, czy to sprawa przycięć w aplikacji, czy otoczenia...

 

Jak najbardziej się zgadzam i dlatego optowałbym np. za nakładaniem limitu CPU jakimś cpulimitem na cały process SSH i wszystkie jego dzieci rekursywnie, przez co nie byłoby takiej sytuacji (bo np. max limit by wynosił 5-10% CPU, a jakby się ktoś postarał to nawet by to podpiął pod samą domenę i usera), a jednocześnie nie trzeba by było szukać workaroundów na problemy, które firma sztucznie powoduje.

 

Zawsze są rozwiązania, które są dobre i dla klienta, i dla firmy. Trzeba tylko się nieco postarać i postawić użyteczność i praktyczność na pewnym zadowalającym poziomie zamiast uciekać od problemu. Wątpię, żeby rozumny klient miał coś przeciw takiemu limitowi - nawet ja bym nie miał, za to jakbym miał jakiś sztuczny limit czasu wykonywania skryptu czy procesu SSH to zostałbym potraktowany jako jakiś niemile widziany gość w tym shellu, a nie faktyczny klient.

Edytowano Lipiec 9, 2016 przez Archi (zobacz historię edycji)

[patryk 451]

Tar to akurat nie taki duży problem dla CPU, a większy dla I/O ;-).

[Pan Kot 1535]

A to jakaś różnica? Dla I/O mamy cgroups.

[patryk 451]

No taka, że napisałeś o limitowaniu CPU, a to akurat w home śmiga od niepamiętnych czasów .

[MikeJones 25]

taaa słynne virtual server overloaded czy tam servicing in progress

[lord101 18]

Potwierdzam, również po około 5 minutach dostaje kilka na tar:

 

tar: Cannot write: broken pipe

tar: Child died with signal 9

tar: Error is not recoverable: exiting now

 

To przypadkiem nie przesada ? Jedynie co działa na ich super hostingu to tylko: cd i ls

Jedyna możliwość przesyłania plików to tylko FTP i plik po pliczku ...