1 |
Sziasztok! |
2 |
|
3 |
Testa <testa.a.tapos@×××××.com> írta (2014. november 27. 2:02): |
4 |
> Szia Peter, |
5 |
> |
6 |
> Alapjaba veve a script csak a logok valtozasanak ellenorzesert felel. |
7 |
> Tehat igen ez nem file olvasas. |
8 |
|
9 |
Nem latom a teljes feladatot, de erre esetleg nem lehetne inotify-t hasznalni? |
10 |
|
11 |
Udvozlettel: |
12 |
Bukuli Norbert |
13 |
|
14 |
> De sajnos a hulye fs bele nyit. |
15 |
> Nos a lenyeg, hogy bele keveredtem egy fogadasba. Egy par fejleszto |
16 |
> akikkel dolgozom keszitett egy php programot ami 1 gigabajtnyi xmlt |
17 |
> dolgoz fel. |
18 |
> A felhaborodasom oka hogy : |
19 |
> -Minden egyes fajlt egyesevel beraknak a tmp-be. |
20 |
> -Majd onnan kiolvasva dolgozak fel es |
21 |
> -Majd minden egyes szekciot egyesevel updatelnek a mysql szerveren. |
22 |
> -Ezzel 12 orara naponta 100% lekra terhelnek 2 magot. (egy a mysql nek |
23 |
> egy a scriptnek.) |
24 |
> -Mondanom se kell mikor meglattam a 80 fokos cpu-t azonnal lelottem a |
25 |
> mysql-t... |
26 |
> -Ebbol vitam lett, es azzal lett lezarva hogy ezt nem lehet maskepp. |
27 |
> -Viszont a fonokuk fogadott velem: Ha kepes vagyok 1 ora alatt |
28 |
> lefutattni egy hasonlot ugy hogy ellenorzom amit a rendszer normal |
29 |
> esetben csinal akkor kirugja ezt a 2 idiotat. De csak nodejs vagy php |
30 |
> lehet C be nem er. |
31 |
> |
32 |
> Nos biztonsagosan -Ofast nelkul -O3 nodejs el a program 40 masodperc |
33 |
> alatt futt le ha a file check futt.(O3 nal nincs hiba) -Ofast os nodejs |
34 |
> el ez 21 masodperc. |
35 |
> |
36 |
> Hat es igen tevedtem. |
37 |
> Mivel a kerdest tokeletesen megoldottam, de sajnos nem magamtol: ki kell |
38 |
> kapcsolni a grsec et. |
39 |
> (Nem eles szerver szoval nem lesz baja 1 napot kibir )... |
40 |
> |
41 |
> |
42 |
> " |
43 |
> |
44 |
> Ezek egyike sem jelent milisec-enkénti korlátozást. Viszont, ha jól |
45 |
> értem ezek olyasmiről szólnak, hogy értesítést lehet kérni a kerneltől |
46 |
> ha egyik vagy másik fájl változik. Valószínű hogy az fs.statSync-ben van |
47 |
> ilyen figyelés is kérve, s azok túl későn lesznek elengedve. Talán |
48 |
> mintha ugyanazon 300 fájlt többszörösen is figyelni próbálná a script. |
49 |
> És lehet hogy csak előre leprogramozott intervallumonként fut le az a |
50 |
> kód ami elengedi a fájl figyelést. Ez pedig programhiba. Ha van elég |
51 |
> memóriád emelheted ezeket a limiteket, jóformán kockázat nélkül. De |
52 |
> azért jobb ha utánaolvasol, hogy pontosan mi a szerepe ezeknek egyenként. |
53 |
> |
54 |
> " |
55 |
> |
56 |
> Majdnem telibe talaltad. |
57 |
> Mielott az elso file el lenne engedve a script nyitja a masikat. |
58 |
> Mivel az fs egy require al jonn a scriptbe. |
59 |
> Megoldas lehetne az is hogy minden file kulon zaras nyitas. Esetleg |
60 |
> tenyleg eldobom a fugvenyt, es ujra hivom mielott |
61 |
> a masik fajlra lepek. De ezzel lassulna a rendszer vagy 2 masodperccel. |
62 |
> Valojaban 19 masodpercen kockaztatom a biztonsagos futtast... Mikor 3600 |
63 |
> alatt kell maradnom szimplan. |
64 |
> Nem kell mondanod tudom hogy hulye vagyok. |
65 |
> |
66 |
> |
67 |
> |
68 |
> " |
69 |
> |
70 |
> Mégis, én inkább nem demóznék egy olyan kétes programot, ami egy stat |
71 |
> hívás-t, mely nem igényel fájl megnyitást sem, nem tud biztonsággal |
72 |
> végrehajtani. Egyébként is, a rendszernek számtalan olyan karbantartási |
73 |
> feladata van melyhez esetenként sok fájlt kell megnyitnia és bezárnia. |
74 |
> Mégis működik nem? |
75 |
> |
76 |
> " |
77 |
> |
78 |
> Na igen de azokat nem egy process nyitja meg egyszerre... |
79 |
> Az alap rendszert csak egy orult forgatja -Ofast al... |
80 |
> |
81 |
> " |
82 |
> |
83 |
> Ez nem kernel-beállítás hanem valami nodejs-sel vagy |
84 |
> a nálad lévő scripttel kapcsolatos hiba lesz. |
85 |
> |
86 |
> " |
87 |
> En nem mondtam hogy nem en vagyok az oka. |
88 |
> Mindent koszi, tenyleg segitettel gondolkozni. |
89 |
> |
90 |
> real 0m20.341s |
91 |
> |
92 |
> Ez kevesebb mint 1 ora. Azt hiszem jo lesz. |
93 |
> Logok neked egy par sorrel. Ha arra jarok megadom. |
94 |
> |
95 |
> Udv |
96 |
> Laszlo |
97 |
> |
98 |
> |
99 |
> On 11/26/14 15:03, Császár Péter wrote: |
100 |
>> Szia László! |
101 |
>> |
102 |
>> Az igen kurta nodejs doksi alapján: |
103 |
>> http://nodejs.org/api/fs.html#fs_fs_statsync_path |
104 |
>> arra tippelek, hogy egészen egyszerű stat rendszerhívás lehet a háttérben: |
105 |
>> http://linux.die.net/man/2/fstat |
106 |
>> |
107 |
>> Márpedig ehhez nem kell megnyitni egy fájlt sem. Továbbra is erősen |
108 |
>> gyanús hogy súlyos programhiba van a háttérben. |
109 |
>> |
110 |
>> Bár a /proc/sys/fs alatti dolgokkal nem vagyok érdemben ismerős, a |
111 |
>> /proc/sys/fs/inotify egy könyvtár és alatt nálam az alábbi fájlok annak |
112 |
>> benne (tartalommal): |
113 |
>> max_queued_events (16384) |
114 |
>> max_user_instances (128) |
115 |
>> max_user_watches (524288) |
116 |
>> |
117 |
>> Ezek egyike sem jelent milisec-enkénti korlátozást. Viszont, ha jól |
118 |
>> értem ezek olyasmiről szólnak, hogy értesítést lehet kérni a kerneltől |
119 |
>> ha egyik vagy másik fájl változik. Valószínű hogy az fs.statSync-ben van |
120 |
>> ilyen figyelés is kérve, s azok túl későn lesznek elengedve. Talán |
121 |
>> mintha ugyanazon 300 fájlt többszörösen is figyelni próbálná a script. |
122 |
>> És lehet hogy csak előre leprogramozott intervallumonként fut le az a |
123 |
>> kód ami elengedi a fájl figyelést. Ez pedig programhiba. Ha van elég |
124 |
>> memóriád emelheted ezeket a limiteket, jóformán kockázat nélkül. De |
125 |
>> azért jobb ha utánaolvasol, hogy pontosan mi a szerepe ezeknek egyenként. |
126 |
>> |
127 |
>> Mégis, én inkább nem demóznék egy olyan kétes programot, ami egy stat |
128 |
>> hívás-t, mely nem igényel fájl megnyitást sem, nem tud biztonsággal |
129 |
>> végrehajtani. Egyébként is, a rendszernek számtalan olyan karbantartási |
130 |
>> feladata van melyhez esetenként sok fájlt kell megnyitnia és bezárnia. |
131 |
>> Mégis működik nem? Ez nem kernel-beállítás hanem valami nodejs-sel vagy |
132 |
>> a nálad lévő scripttel kapcsolatos hiba lesz. |
133 |
>> |
134 |
>> Üdv, |
135 |
>> Péter |
136 |
>> |
137 |
>> 2014-11-26 14:13 keltezéssel, Testa írta: |
138 |
>>> Szia Peter, |
139 |
>>> |
140 |
>>> Koszi a valaszod. |
141 |
>>> Meg egzsyer meg probalom meg fogalmazni. |
142 |
>>> Egy 200 sorros scriptrol beszelunk ami egy set interval utan csinal 300 |
143 |
>>> fs.statSync et... (ha read lenne akkor lassabb lenne es nem lepne fel a |
144 |
>>> hiba.) |
145 |
>>> Persze tudom hogy az emelt file rendszer cache a fo ok amiert ilyen |
146 |
>>> gyorsan kepes az olvasast vegre hajtani a rendszer. Szoval technikailag |
147 |
>>> az en hibam is. De szuksegem van erre a teljesitmenyre... ( Mivel a |
148 |
>>> rendszer egy demonstracio ) |
149 |
>>> |
150 |
>>> A problema az hogy a linux kernel 8 file megnyisat teszi lehetove ms |
151 |
>>> ekenkent... Probaltam a /proc/sys/fs be meg talalni a erre a megoldast. |
152 |
>>> Ugyan meg is talaltam a /proc/sys/fs/inotify ba amit keresek. De ezt nem |
153 |
>>> merem 300 ra allitani. Ha persze a programot le lassitom akkor |
154 |
>>> tokeletesen fut. Viszont nem hiszem hogy ez hosszu tavon jo megoldas... |
155 |
>>> (Teny jelenleg ezt a modszert valasztottam) |
156 |
>>> |
157 |
>>> |
158 |
>>> Udv |
159 |
>>> Laszlo |
160 |
>>> |
161 |
>>> On 11/26/14 12:50, Császár Péter wrote: |
162 |
>>>> Szia Testa, |
163 |
>>>> |
164 |
>>>> Kissé homályos hogy mi is történik pontosan, de majdnem biztos vagyok |
165 |
>>>> benne hogy vagy az a nodejs progi, vagy az általa használt libekben |
166 |
>>>> valahol súlyos hiba van. Helyesen megírt program nem fog elszállni csak |
167 |
>>>> mert gyorsabb gépet teszünk alá. |
168 |
>>>> |
169 |
>>>> Szóval a helyedben én írnék egy bugriportot, ha fontos ez a program a |
170 |
>>>> számodra. |
171 |
>>>> |
172 |
>>>> Üdv, |
173 |
>>>> Péter |
174 |
>>>> |
175 |
>>>> 2014-11-26 13:08 keltezéssel, Testa írta: |
176 |
>>>>> Hello mindenki, |
177 |
>>>>> |
178 |
>>>>> Tenyleg olyan hibam van amit nehez elhinni. |
179 |
>>>>> Nem gentoos hiba de remelem lesz valakinek otlete. |
180 |
>>>>> Szoval. Adott egy nodejs program ami olvas a file 300 filet. |
181 |
>>>>> Ezt elvegzi minden masodpercben. |
182 |
>>>>> A program tokeletesen mukodik majdnem minden desktopon. |
183 |
>>>>> Ha az nem i7 es a merevlemez nem egy jo gyors ssd es nincs szanaszet |
184 |
>>>>> optimalizalt gentoo a rendszeren. |
185 |
>>>>> Sajnos ssd -n plusz i7-en vagy xeon-on olyan gyors hgy a sigserv kilovi. |
186 |
>>>>> (XEON on mar az elso olvasas meghal, i7 en en csak a madsodik ellenorzes) |
187 |
>>>>> Sajonos ez nodejs es nem tudok wait-et/sleep-et hasznalni. |
188 |
>>>>> Van ra mod hogy a file limitet/ms -et atirjam ? |
189 |
>>>>> |
190 |
>>>>> |
191 |
>>>>> Elore is koszi. |
192 |
>>>>> |
193 |
>>> |
194 |
>> |
195 |
> |
196 |
> |