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

[Testa]

Szia Peter,

Alapjaba veve a script csak a logok valtozasanak ellenorzesert felel.
Tehat igen ez nem file olvasas.
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.
>>>>
>>
>