[gentoo-user-hu] Az evszazad poenja.

[gentoo-user-hu] Az evszazad poenja.

[Testa]

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.

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

[Császár Péter]

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

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

[Testa]

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

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

[Testa]

Majdnem elfelejtettem :P A nodejs -Ofast al lett forditva szoval
kapasbol nincs ertelme reportolnom...

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

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

[Császár Péter]

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

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

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

[Bukuli Norbert]

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

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

[Testa]

[-- Attachment #1: Type: text/plain, Size: 8307 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 9693 bytes --]