Re: [gentoo-user-hu] Az evszazad poenja.

[Testa]

Hello Norbi,

Gondoltam rá. De összesen 24 órám volt a feladatra.
Találtam is 3 jónak tűnő megoldást. Sajnos feladtam mert csak 2 volt npm
be.

https://www.npmjs.org/package/watch-inotify

https://www.npmjs.org/package/inotify-plusplus

Egyik se volt hajlandó magától npm -g install al felmenni. De végleges
megoldásnak egyértelműen az inotify a legjobb.



Udv
Laszlo

On 11/27/14 05:27, Bukuli Norbert wrote:
> Sziasztok!
>
> Testa <testa.a.tapos@×××××.com> írta (2014. november 27. 2:02):
>> Szia Peter,
>>
>> Alapjaba veve a script csak a logok valtozasanak ellenorzesert felel.
>> Tehat igen ez nem file olvasas.
> Nem latom a teljes feladatot, de erre esetleg nem lehetne inotify-t hasznalni?
>
> Udvozlettel:
> Bukuli Norbert
>
>> De sajnos a hulye fs bele nyit.
>> Nos a lenyeg, hogy bele keveredtem egy fogadasba.  Egy par fejleszto
>> akikkel dolgozom keszitett egy php programot ami 1 gigabajtnyi xmlt
>> dolgoz fel.
>> A felhaborodasom oka hogy :
>> -Minden egyes fajlt egyesevel beraknak a tmp-be.
>> -Majd onnan kiolvasva dolgozak fel es
>> -Majd minden egyes szekciot egyesevel updatelnek a mysql szerveren.
>> -Ezzel 12 orara naponta 100% lekra terhelnek 2 magot. (egy a mysql nek
>> egy a scriptnek.)
>> -Mondanom se kell mikor meglattam a 80 fokos cpu-t azonnal lelottem a
>> mysql-t...
>> -Ebbol vitam lett, es azzal lett lezarva hogy ezt nem lehet maskepp.
>> -Viszont a fonokuk fogadott velem: Ha kepes vagyok 1 ora alatt
>> lefutattni egy hasonlot ugy hogy ellenorzom amit a rendszer normal
>> esetben csinal akkor kirugja ezt a 2 idiotat. De csak nodejs vagy php
>> lehet C be nem er.
>>
>> Nos biztonsagosan -Ofast nelkul -O3 nodejs el a program 40 masodperc
>> alatt futt le ha a file check futt.(O3 nal nincs hiba) -Ofast os nodejs
>> el ez 21 masodperc.
>>
>> Hat es igen tevedtem.
>> Mivel a kerdest tokeletesen megoldottam, de sajnos nem magamtol: ki kell
>> kapcsolni a grsec et.
>> (Nem eles szerver szoval nem lesz baja 1 napot kibir )...
>>
>>
>> "
>>
>> Ezek egyike sem jelent milisec-enkénti korlátozást. Viszont, ha jól
>> értem ezek olyasmiről szólnak, hogy értesítést lehet kérni a kerneltől
>> ha egyik vagy másik fájl változik. Valószínű hogy az fs.statSync-ben van
>> ilyen figyelés is kérve, s azok túl későn lesznek elengedve. Talán
>> mintha ugyanazon 300 fájlt többszörösen is figyelni próbálná a script.
>> És lehet hogy csak előre leprogramozott intervallumonként fut le az a
>> kód ami elengedi a fájl figyelést. Ez pedig programhiba. Ha van elég
>> memóriád emelheted ezeket a limiteket, jóformán kockázat nélkül. De
>> azért jobb ha utánaolvasol, hogy pontosan mi a szerepe ezeknek egyenként.
>>
>> "
>>
>> Majdnem telibe talaltad.
>> Mielott az elso file el lenne engedve a script nyitja a masikat.
>> Mivel az fs egy require al jonn a scriptbe.
>> Megoldas lehetne az is hogy minden file kulon zaras nyitas. Esetleg
>> tenyleg eldobom a fugvenyt, es ujra hivom mielott
>> a masik fajlra lepek. De ezzel lassulna a rendszer vagy 2 masodperccel.
>> Valojaban 19 masodpercen kockaztatom a biztonsagos futtast... Mikor 3600
>> alatt kell maradnom szimplan.
>> Nem kell mondanod tudom hogy hulye vagyok.
>>
>>
>>
>> "
>>
>> Mégis, én inkább nem demóznék egy olyan kétes programot, ami egy stat
>> hívás-t, mely nem igényel fájl megnyitást sem, nem tud biztonsággal
>> végrehajtani. Egyébként is, a rendszernek számtalan olyan karbantartási
>> feladata van melyhez esetenként sok fájlt kell megnyitnia és bezárnia.
>> Mégis működik nem?
>>
>> "
>>
>> Na igen de azokat nem egy process nyitja meg egyszerre...
>> Az alap rendszert csak egy orult forgatja -Ofast al...
>>
>> "
>>
>> Ez nem kernel-beállítás hanem valami nodejs-sel vagy
>> a nálad lévő scripttel kapcsolatos hiba lesz.
>>
>> "
>> En nem mondtam hogy nem en vagyok az oka.
>> Mindent koszi, tenyleg segitettel gondolkozni.
>>
>> real    0m20.341s
>>
>> Ez kevesebb mint 1 ora. Azt hiszem jo lesz.
>> Logok neked egy par sorrel. Ha arra jarok megadom.
>>
>> Udv
>> Laszlo
>>
>>
>> On 11/26/14 15:03, Császár Péter wrote:
>>> Szia László!
>>>
>>> Az igen kurta nodejs doksi alapján:
>>> http://nodejs.org/api/fs.html#fs_fs_statsync_path
>>> arra tippelek, hogy egészen egyszerű stat rendszerhívás lehet a háttérben:
>>> http://linux.die.net/man/2/fstat
>>>
>>> Márpedig ehhez nem kell megnyitni egy fájlt sem. Továbbra is erősen
>>> gyanús hogy súlyos programhiba van a háttérben.
>>>
>>> Bár a /proc/sys/fs alatti dolgokkal nem vagyok érdemben ismerős, a
>>> /proc/sys/fs/inotify egy könyvtár és alatt nálam az alábbi fájlok annak
>>> benne (tartalommal):
>>> max_queued_events (16384)
>>> max_user_instances (128)
>>> max_user_watches (524288)
>>>
>>> Ezek egyike sem jelent milisec-enkénti korlátozást. Viszont, ha jól
>>> értem ezek olyasmiről szólnak, hogy értesítést lehet kérni a kerneltől
>>> ha egyik vagy másik fájl változik. Valószínű hogy az fs.statSync-ben van
>>> ilyen figyelés is kérve, s azok túl későn lesznek elengedve. Talán
>>> mintha ugyanazon 300 fájlt többszörösen is figyelni próbálná a script.
>>> És lehet hogy csak előre leprogramozott intervallumonként fut le az a
>>> kód ami elengedi a fájl figyelést. Ez pedig programhiba. Ha van elég
>>> memóriád emelheted ezeket a limiteket, jóformán kockázat nélkül. De
>>> azért jobb ha utánaolvasol, hogy pontosan mi a szerepe ezeknek egyenként.
>>>
>>> Mégis, én inkább nem demóznék egy olyan kétes programot, ami egy stat
>>> hívás-t, mely nem igényel fájl megnyitást sem, nem tud biztonsággal
>>> végrehajtani. Egyébként is, a rendszernek számtalan olyan karbantartási
>>> feladata van melyhez esetenként sok fájlt kell megnyitnia és bezárnia.
>>> Mégis működik nem? Ez nem kernel-beállítás hanem valami nodejs-sel vagy
>>> a nálad lévő scripttel kapcsolatos hiba lesz.
>>>
>>> Üdv,
>>> Péter
>>>
>>> 2014-11-26 14:13 keltezéssel, Testa írta:
>>>> Szia Peter,
>>>>
>>>> Koszi a valaszod.
>>>> Meg egzsyer meg probalom meg fogalmazni.
>>>> Egy 200 sorros scriptrol beszelunk ami egy set interval utan csinal 300
>>>> fs.statSync et... (ha read lenne akkor lassabb lenne es nem lepne fel a
>>>> hiba.)
>>>> Persze tudom hogy az emelt file rendszer cache a fo ok amiert ilyen
>>>> gyorsan kepes az olvasast vegre hajtani a rendszer. Szoval technikailag
>>>> az en hibam is. De szuksegem van erre a teljesitmenyre... ( Mivel a
>>>> rendszer egy demonstracio )
>>>>
>>>> A problema az hogy a linux kernel 8 file megnyisat teszi lehetove ms
>>>> ekenkent... Probaltam a /proc/sys/fs be meg talalni a erre a megoldast.
>>>> Ugyan meg is talaltam a /proc/sys/fs/inotify ba amit keresek. De ezt nem
>>>> merem 300 ra allitani. Ha persze a programot le lassitom akkor
>>>> tokeletesen fut. Viszont nem hiszem hogy ez hosszu tavon jo megoldas...
>>>> (Teny jelenleg ezt a modszert valasztottam)
>>>>
>>>>
>>>> Udv
>>>> Laszlo
>>>>
>>>> On 11/26/14 12:50, Császár Péter wrote:
>>>>> Szia Testa,
>>>>>
>>>>> Kissé homályos hogy mi is történik pontosan, de majdnem biztos vagyok
>>>>> benne hogy vagy az a nodejs progi, vagy az általa használt libekben
>>>>> valahol súlyos hiba van. Helyesen megírt program nem fog elszállni csak
>>>>> mert gyorsabb gépet teszünk alá.
>>>>>
>>>>> Szóval a helyedben én írnék egy bugriportot, ha fontos ez a program a
>>>>> számodra.
>>>>>
>>>>> Üdv,
>>>>> Péter
>>>>>
>>>>> 2014-11-26 13:08 keltezéssel, Testa írta:
>>>>>> Hello mindenki,
>>>>>>
>>>>>> Tenyleg olyan hibam van amit nehez elhinni.
>>>>>> Nem gentoos hiba de remelem lesz valakinek otlete.
>>>>>> Szoval. Adott egy nodejs program ami olvas a file 300 filet.
>>>>>> Ezt elvegzi minden masodpercben.
>>>>>> A program tokeletesen mukodik majdnem minden desktopon.
>>>>>> Ha az nem i7 es a merevlemez nem egy jo gyors ssd es nincs szanaszet
>>>>>> optimalizalt gentoo a rendszeren.
>>>>>> Sajnos ssd -n plusz i7-en vagy xeon-on olyan gyors hgy a sigserv kilovi.
>>>>>> (XEON on mar az elso olvasas meghal, i7 en en csak a madsodik ellenorzes)
>>>>>> Sajonos ez nodejs es nem tudok wait-et/sleep-et hasznalni.
>>>>>> Van ra mod hogy a file limitet/ms -et atirjam ?
>>>>>>
>>>>>>
>>>>>> Elore is koszi.
>>>>>>
>>
>