Sziasztok!

Testa <testa.a.tapos@gmail.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.