# Backup dcron - CPU & RAM

## soban_

Chcialbym poruszyc pewna kwestie dotyczaca backupowanie danego folderu, mamy sobie skrypcior ktory taruje i traktuje lzma folder zeby nie przytaczac calosc dam kawalek:

```
...

TAR="nice -n 19 tar -cp"

PAKER="nice -n 19 lzma -4"

$TAR /home/sciezka/do/folderu | $PAKER > minecraft_rpg_$TIME.tar.lzma

...
```

Sobie jest dodanych pare takich skryptow i one wykonuje sie w cronie systematycznie co 2h, jako ze w tym przypadku w ogole nie zalezy mi na czasie. Chcialbym aby one jak najmniej obciazaly moj CPU + RAM, teraz powstaja nastepujace pytania. Czy lepiej jest odpalac te skrypty jednoczesnie mianowicie (/var/spool/cron/crontabs/root):

```
0 */2 * * * cpulimit --limit 30 /home/pierwszy/skrypt &> /dev/null

0 */2 * * * cpulimit --limit 30 /home/drugi/skrypt &> /dev/null
```

Czy moze tak lepiej:

```
0 */2 * * * cpulimit --limit 30 /home/pierwszy/skrypt &> /dev/null && cpulimit --limit 30 /home/drugi/skrypt &> /dev/null
```

aby poczekal az sie pierwszy wykona i bral sie za drugi. Procesor to i7, w sumie nie wadzi ten backup, ale chcialbym go jak najmocniej ograniczyc - podkreslam nie zalezy mi na czasie, zalezy mi na tym zeby jak najmniej zajmowal procka i RAMu (co do cpulimit - tak @SlashBeast, juz sie zabieram za czytanie o cgroups). I teraz czy RAM bedzie zajety dluzej, jesli ogranicze procesor? Chcialbym to zrobic jak najekonomiczniej kosztem czasu, wszelkie podpowiedzi sa mile widziane.

----------

## SlashBeast

Jak odpalasz to z roota to utworz cgroupe, dodaj tam limity na IO, ram, procesor, dodaj pid skryptu 'echo $$ > /sys/fs/cgroups/backuuper/tasks' i tyle, wszystkie childy beda dodawane tam automatycznie.

Swoja droga to uzywanie &> w cronie to bardzo zly pomysl. Cron uzywa /bin/sh i o ile masz /bin/sh linkiem do basha to bedzie dzialac, natomiast prawdziwe /bin/sh nie obsluguje takiego czegos i tam winnes uzyc > /dev/null 2>&1.

----------

## soban_

No ok, tylko pytanko jak sensownie to ograniczyc zeby mialo to rzeczywiscie zaistniec (chcialbym aby sie wyrobil w 2h pakujac to) rozmiar koncowy to jakies 1-4gb i czy rzeczywiscie takie ograniczanie ma sens? W sensie kosztem RAMu i czasu, czy lepiej z pelnej pary szybko to spakowac i miec z glowy? Oczywiscie w tle chodza tam sobie rozne aplikacje z ktorych korzystaja ludzie on-line, dlatego bym chcial to jakos sensownie rozwiazac - aby byli uzytkownicy zadowoleni, bez posiadania lagow etc. Ewentualnie czy nie lepiej w nocy - gdzie jest mniejsza ich ilosc wszystko pakowac lzma i kasowac pliki tar? No i czy takie ograniczanie ma sens? Bo przy mniejszej mozliwosc obliczen, RAM bedzie dluzej zajety - zarezerowany na pakowanie? 

Albo w druga strone, czy mozna ustawic tak aplikacje (wiem ze nice to robi, jednak wydaje mi sie ze nie do konca - bo mialy miejsce wywrotki przez obciazenie nice -n -20 - chyba ze bym musial wszystkie pozostale na 19 ustawic) jednak czy mozna ustawic dana aplikacji, aby zawsze miala zarezerwowana ilosc ramu + procesor - ze tak powiem, aby byla traktowana priorytetowo, najlepiej - aby nie bylo mozliwosci jej zawieszenia poprzez np rezerwacje duzej ilosci ramu przez inna aplikacje? I zeby nigdy nie musiala wchodzic na swap? *SlashBeast wrote:*   

> Swoja droga to uzywanie &> w cronie to bardzo zly pomysl. Cron uzywa /bin/sh i o ile masz /bin/sh linkiem do basha to bedzie dzialac, natomiast prawdziwe /bin/sh nie obsluguje takiego czegos i tam winnes uzyc > /dev/null 2>&1.

 OK juz poprawiam, dzieki (-:

----------

