From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6C61B1389E2 for ; Thu, 27 Nov 2014 12:47:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CCEF8E088D; Thu, 27 Nov 2014 12:47:26 +0000 (UTC) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 24672E088D for ; Thu, 27 Nov 2014 12:47:25 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id ex7so15622749wid.15 for ; Thu, 27 Nov 2014 04:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=iszGJzeloi3XWygomxyD1XGG7Y/x3+CoxF/HrSPIm3Q=; b=OG7kfeJfJ0s4dgCF0bgKWDdIljIXHpICsrVaJS0KKXUDhqmEjkwLpfMrgXKCuOZYzV ANjkCogWuYZQ0I/QY+MotyCts3DqqsTWJgbulMCVTor6+zkUJa4lyDnSI/nmMfA0mEa9 g6EYliGquU2nX+5cyZoLjuIgS8rDyN9ycbdDx3H+Kk6hJNjSVYbbHttRjz0D/pPdZNc9 HYbszuHJzoO1yKU9cIXFhAkjLmg+GOlbOn0HvFQmGP3M3EmjYh4x3Uv7GyqPYpDdXw1v 91h3HRcE53T4pRYxgUkcT5itOYGvlZNgMBhq+qUihXbyoV4Nc+Aw0vqZw84EYDtM+cq6 FxiA== X-Received: by 10.180.76.80 with SMTP id i16mr9194316wiw.61.1417092444653; Thu, 27 Nov 2014 04:47:24 -0800 (PST) Received: from [192.168.1.8] (cpc2-rdng20-2-0-cust745.15-3.cable.virginm.net. [86.28.166.234]) by mx.google.com with ESMTPSA id fq1sm25133988wib.12.2014.11.27.04.47.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Nov 2014 04:47:24 -0800 (PST) Message-ID: <54771D82.90505@gmail.com> Date: Thu, 27 Nov 2014 12:48:02 +0000 From: Testa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user-hu@lists.gentoo.org Reply-to: gentoo-user-hu@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user-hu@lists.gentoo.org Subject: Re: [gentoo-user-hu] Az evszazad poenja. References: <5475C2CF.8060709@gmail.com> <5475CCA5.6060005@gmail.com> <5475D20B.4020204@gmail.com> <5475EBDF.4000003@gmail.com> <54767820.3@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000204020608000506090101" X-Archives-Salt: 43793010-0217-45f2-9daa-2de2183555a1 X-Archives-Hash: 18bd393be9fcb1d68672ae4b19058344 This is a multi-part message in MIME format. --------------000204020608000506090101 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 í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. >>>>>> >> > --------------000204020608000506090101 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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.



          

          

        

        



      

      



    

    

  


--------------000204020608000506090101--