cyklus v cronu?

[okoun]

Nevím prosím někdo z váš zkušených linuxáků jak toto zapsat cronu toto pomocí nějakého cyklu abych nemusel jako blbeček vypisovat toto:

Kód: Vybrat vše

 */1 * * * * php cron_snmp.php 1 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 2 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 3 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 4 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 5 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 6 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 7 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 8 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 9 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 10 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 11 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 12 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 13 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 14 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 15 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 16 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 17 >/dev/null 2>&1
 */1 * * * * php cron_snmp.php 18 >/dev/null 2>&1

soubor cron_snmp obsluhuje už tolik zařízení že nestačí získat údaje do 1 minuty takže to takto musím rozdělit a potřeboval bych tedy tím cyklem přičítat tu $argv['1'] proměnnou od 1 do 20 či více podle potřeby...

[forkman]

Co si to cyklovat v tom skriptu třeba podle aktuální minuty, kdy se cron spustil. Když jich je 20, je to ideál a když jich budeš potřebovat 30, je to jen malá úprava

[okoun]

nelze, ten script v tom cronu musím volat minimálně 20x ve stejný čás možná i vícekrát abych stačil vše vyčíst

[rsaf]

Odcyklovat ve skriptu ale spouštět v pozadí - např. přidáním znaku & na konec řádku...

[okoun]

hmm nějak nechápu, když dám do cronu jeden příkaz tak si potom v tom kodu mohu cyklovat co chci ale vždy to bude provádět postupně. já ale potřebuji aby to prováděl paralelně. nebo prosím uvést nějaký příklad jeslti to špatně chápu jak to myslíš...

[rsaf]

Kód: Vybrat vše

#!/bin/bash
for I in 8.8.8.8 8.8.4.4 do
   ping -c 3 $I &
done


Cyklus do proměnné I dá postupně dvě IP adresy, ty dá jako parametr příkazu PING. Díky znaku & na konci řádku s příkazem ping se ping spustí tak nějak v pozadí = bez čekání = oba pingy běží najednou a výpisy v konzoli se "míchají",takže výstup vypadá nějak takto...

PING 8.8.8.8 (8.8.8. 56(84) bytes of data.
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=6.82 ms
64 bytes from 8.8.4.4: icmp_seq=1 ttl=55 time=6.80 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=55 time=6.74 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=6.84 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=55 time=6.76 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=6.78 ms

[ludvik]

Podívej se na GNU parallel

Ale asi by nebyl problém to obalit dalším php scriptem, co si to spustí. Nebo naprosto jednoduchý for cyklus v bashi https://www.linuxexpres.cz/praxe/bash-9-dil

[okoun]

takže tento soubor spustit jedním spouštěčem v cronu?

Kód: Vybrat vše

*/1 * * * * cron.bash >/dev/null 2>&1

Kód: Vybrat vše

#!/bin/bash

for a in $( seq 20 )
do php cron_snmp.php ${a} >/dev/null 2>&1 &
done

[rsaf]

Teoreticky ano... Otázka je, zda je to takto správně vymyšlené a zda se nemá optimalizovat ještě jinak

Příklad:
Napsal se skript, který sekvenčně přes SNMP očichává něco na síti. Pouštělo se to co minuto a bylo to OK. S rostoucí sítí to přestalo stíhat za minutu projet všechna zařízení, takže se zařízení rozdělila na 4 skupiny a očichávají se 4 skripty paralelně. Dnes jsme ze 4 na 20, příští rok to může být 50...
Co se stane při havárii na síti kdy stovky zařízení neodpovídají, čeká se u každého zařízení 3 sec na tomeout...? Nejspíš každý jeden skript místo méně než minuty pojede minut 15, takže se na tom stroji postupně spustí stovky nebo i tisíce procesů...
Udělal bych spíše něco jako frontu nebo plánovač - požadavek na komunikaci se zařízením se dá do fronty, ovšem jen v případě, že tam ještě není. Potom poběží trvale spuštěno 20 daemonů, kteří si budou z fronty úlohy vyzvedávat a zpracovávat je...

[okoun]

nene 3 sec nečeká, čeká cca 0,5sec
každopádně ta fronta by to potom asi rozhodila takto to mělo cacti a to fungovalo velmi zle. Ono je lepší jít cestou třeba 50-100 procesů paraelně ono potom i při nedostupnosti sítě to pude hluboce pod minotou...

úplně nejlepší řešení by bylo zkompilovat to php pro vícevláknofou funkci přimo ve scriptu ale to je prý nějak hodně složité či co...
mě by tedy třeba zajímalo jak toto řeší zabbix, každopádně zabbix jsem zkoušel a je to šílenej žrout výkonu serveru

[forkman]

A co tam máte chlapi tak důležitýho, že potřebujete každou minutu projet celou síť ?:-) Chcete mít bandwidth grafy s rozlišením 1px

[okoun]

nu dříve jsem používal 5 minut ale na spousta věcí to je málo... třeba vytížení linky, chybovost linky, zítěž cpu....

[forkman]

Na tyhle věci jsou spíš lepší trapy, nemusíš je hledat, ozvou se samy

[Dalibor Toman]

dulezite je, aby se slepovaly pozadavky na jedno zarizeni do jednoho (nebo vice pokud se do jednoho nevejdou) packetu, aby se udrzoval blacklist zarizeni, ktera neodpovidaji (aby pripadny dalsi dotaz nezdrzoval). Optimalni by bylo vyuzit jeste strom zavislosti a pri nedostupnosti jednoho zarizeni se neobtezovat vycitat ty za nim.

60000 merenych velicin u nas vygeneruje 3200 SNMP requestu a cele i s ulozenim do remote PostgreSQL to probehne aktualne za 18sec. Pred par mesici to byvalo 11sec - SQL faze se nam nejak protahla (ta trva ted az 8 sec). Kvuli optimalizaci casu insertu to bezi na 32 vlaknech
Paralelne k SQL verzi bezi jeste stara, ktera uklada do RRD celkem v 6ti vlaknech a ta bezi cca 40 sekund.

V obou pripadech je sber a ukladani dat realizovan Cckovou binarkou.

co se tyce paralelniho spousteni skriptu z cronu - s tim "&" bych byl opatrnejsi. Pocitove z toho mam obavy - urcite bude nastavat situace, ze ty skripty zustanou viset v pameti. Radeji bych napsal v perlu/php nebo necem podobnem nejaky wrapper, ktery ty skripty spusti jako child procesy a pocka si na jejich ukonceni, pripadne je sam postrili, kdyz bude sam sestrelen killem. Mimo jine muze nekam (treba do grafu) logovat jak dlouho ten beh skriptu trval, aby se vedelo, za se vycitani nezacina 'kousat do ocasu' apod.

[okoun]

Teoreticky ano... Otázka je, zda je to takto správně vymyšlené a zda se nemá optimalizovat ještě jinak

Příklad:
Napsal se skript, který sekvenčně přes SNMP očichává něco na síti. Pouštělo se to co minuto a bylo to OK. S rostoucí sítí to přestalo stíhat za minutu projet všechna zařízení, takže se zařízení rozdělila na 4 skupiny a očichávají se 4 skripty paralelně. Dnes jsme ze 4 na 20, příští rok to může být 50...
Co se stane při havárii na síti kdy stovky zařízení neodpovídají, čeká se u každého zařízení 3 sec na tomeout...? Nejspíš každý jeden skript místo méně než minuty pojede minut 15, takže se na tom stroji postupně spustí stovky nebo i tisíce procesů...
Udělal bych spíše něco jako frontu nebo plánovač - požadavek na komunikaci se zařízením se dá do fronty, ovšem jen v případě, že tam ještě není. Potom poběží trvale spuštěno 20 daemonů, kteří si budou z fronty úlohy vyzvedávat a zpracovávat je..

#!/bin/bash

for a in $( seq 52 )
do php cron_snmp.php ${a} >/dev/null 2>&1 &
done

hmm začal jsem mít s tím problém a to že se mi stane že třeba u hodnoty 50 když ten script pracuje třeba trochu déle, třeba 20 sec tak prostě nedojede a už se spustí 51, nevím tedy kde hledat co abych prodloužil nějaký timeout někde?