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

[Bukuli Norbert]

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.
>>>>>
>>>
>>
>
>