mysql cpu korlátozás

Fórumok

mysql cpu korlátozás

Hozzászólások

[quote:7667778caf="Jonci"][quote:7667778caf="lacika"]/etc/init.d/mysql restart megoldotta a problémát.

erre írtam, ezt helyetted a monit automatikusan meg tudja csinalni,
ha egy program valamiért elkezdené zabálni a memóriát és/vagy procit stb. akkor újraindítja, hátha segít, de mail-t is tudsz vele küldenit, hogy baj van (pl telefonra, stb)

Ige, tudom hogy ezeket is tudja. Ilyen szempontból nagyon jó, és hasznos. De azokra a kérdésekre is választ keresek, melyek szerint érdemes -e 2.6 -os sorozatú kernelre váltani, érdemes -e 5 -ös sorozatú MySQL adatbázist használni, és hogy mennyivel segítene a jelenlegi 2,4 celeron helyett egy 3 GHzs "rendes" Intel proci. De köszönöm neked is a segítséget. Be fogom üzemelni a monit -ot :).

sarge rendszer

nálunk az összes szerver 2.6-os sajatforditasu kernellel fut,
semmi gond nincs velük, UML-ek is futnak rendesen

mysql-ből a sarge 4.0.24-es megy és semmi gond nincs vele
jó, nincsenek hatalmas táblák, de a fejlesztés alatt egy p2@333-on futott 2.6-os kernellel 192mb rammal non-stop és bírta, nem omlott össze soha

[quote:5d96a70d74="Jonci"]sarge rendszer

nálunk az összes szerver 2.6-os sajatforditasu kernellel fut,
semmi gond nincs velük, UML-ek is futnak rendesen

mysql-ből a sarge 4.0.24-es megy és semmi gond nincs vele
jó, nincsenek hatalmas táblák, de a fejlesztés alatt egy p2@333-on futott 2.6-os kernellel 192mb rammal non-stop és bírta, nem omlott össze soha

Nem tudom, hogy fejlesztés alatt mennyi kérés érkezett az sql adatbázisodhoz. Pontos adatot most nem tudok per pillanat, csak arra emlékszem, hogy amit kiszolgált weboldalak (2 db) napi szinten ~ 30000 látogatót vonzott és a két weboldalt ~ 6 millió találat érte (awstats szerint) és erősen mysql alapúak ezek az oldalak. És nem az apache omlott össze hanem a mysql. Ha lesz időm, megnézem, hogy kb mennyi sql kérés érkezett a szerverhez napi szinten, de szerintem sok lesz :).

azért is írtam, hogy fejlesztés, mert ezekhez a számokhoz képest nevetséges

de ezen számok tükrében már más a leányzó fekvése:)
bár, most lehet hülyeséget mondok, de ilyen procin, ekkora terhelés mellett a 2.6-os kernel szerintem jobban muzsikalna

a my.cnf módosításával is lehet elérni jelentős javulásokat (és romlásokat :) ), bár gondolom ez volt az első

[quote:fb3c7b75a2="Jonci"]azért is írtam, hogy fejlesztés, mert ezekhez a számokhoz képest nevetséges

de ezen számok tükrében már más a leányzó fekvése:)
bár, most lehet hülyeséget mondok, de ilyen procin, ekkora terhelés mellett a 2.6-os kernel szerintem jobban muzsikalna

a my.cnf módosításával is lehet elérni jelentős javulásokat (és romlásokat :) ), bár gondolom ez volt az első

A my.cnf -et szeintem relatív jól állítottam be (pontosabban a mysql.com oldalon lévő dokumetációk alapján).
De itt van:
key_buffer_size = 16M
table_cache = 256
sort_buffer_size = 4M
read_buffer_size = 1M
max_allowed_packet = 2M
thread_stack = 1M
max_connections = 350
query_cache_limit = 1048576
query_cache_size = 26214400
query_cache_type = 1
A lényeges beállítások ezek. Ha itt lenne nagy marhaság, akkor szóljatok kérlek.
Én is gondolkodtam a 2.6 -os kernelen. Az kb. mekkora javulást hozna?

"huge" adatbázishoz egy ajánlott beállítás (persze a tárolt adatoktól és az adatbázis használatától függően változhatnak az értékek):

key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

[quote:8957a6db89="Jonci"]"huge" adatbázishoz egy ajánlott beállítás (persze a tárolt adatoktól és az adatbázis használatától függően változhatnak az értékek):

key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

Igen, ezzel én is találkoztam már. A key_buffer -re viszont azt írták, hogy ha nincs túl sok RAM, de terhelt az adatbázis, célszerűbb kisebb értékre venni. Vagy én nem értettem jól esetleg?

[quote:e3694419d1="lacika"]Igen, ezzel én is találkoztam már. A key_buffer -re viszont azt írták, hogy ha nincs túl sok RAM, de terhelt az adatbázis, célszerűbb kisebb értékre venni. Vagy én nem értettem jól esetleg?

jó kérdés, még nem volt a kezem alatt ekkora igénybevételű adatbázis

most hogy nézem, ezek vannak a gépben nálad: jelenleg 1x512 MB & 1x256 MB
a leírás szerint azonban:

"This is for a large system with memory of 1G-2G where the system runs mainly MySQL."

sza próbálj meg belerakni ideiglenesen valahonnan még minimum 512-t aztán próbáld meg, hogy teljesít a küldött conf-fal, és ha érezhetően javul a helyzet, csak akkor indulj boltba, persze imho

[quote:b93df2a187="Jonci"][quote:b93df2a187="lacika"]Igen, ezzel én is találkoztam már. A key_buffer -re viszont azt írták, hogy ha nincs túl sok RAM, de terhelt az adatbázis, célszerűbb kisebb értékre venni. Vagy én nem értettem jól esetleg?

jó kérdés, még nem volt a kezem alatt ekkora igénybevételű adatbázis

most hogy nézem, ezek vannak a gépben nálad: jelenleg 1x512 MB & 1x256 MB
a leírás szerint azonban:

"This is for a large system with memory of 1G-2G where the system runs mainly MySQL."

sza próbálj meg belerakni ideiglenesen valahonnan még minimum 512-t aztán próbáld meg, hogy teljesít a küldött conf-fal, és ha érezhetően javul a helyzet, csak akkor indulj boltba, persze imho

Pénteken tudom lecserélni a ramokat, így 2 GB lesz benne, meg a 2,4 Celeront egy 3 GHz -esre (nem cerka). Akkor majd meglátjuk mi lesz a helyzet. Köszike a segítséget!

Sziasztok,

Van egy debian woody, amin fut egy mysql. Szegény mysql eléggé le van terhelve. Történt ma, hogy ~5 percig tartott, amíg be tudtam ssh -zni a szerverre. Nyomtam egy uptime -ot és ott láttam
load avarage: 205.24 174.74 183.78
Ez egy kicsit magas. Majd megnéztem melyik folyamat eszik meg ennyire a procit. Láttam, hogy a mysql. /etc/init.d/mysql restart megoldotta a problémát. De amíg ennyire nagy volt a load normál időn belül semmit nem tudott kiszolgálni a szerver. Ez baj volt sajnos. Találtam a /etc/security/limits.conf fájlt.
Gondoltam arra, hogy felveszem a következő sort:
mysql hard cpu ?
A kérdőjel helyére kellene a megengedett processzoridő percben a leírás szerint. Ide mennyit kellene írni? 2.6 GHz Intel P4 a proci. De ahogy olvasgattam a googlival talált oldalakat, számomra az jött le, hogy a háttérben futó folyamatok előbb-utóbb elérik ezt az értéket, és a processz ki lesz gyilkolva. Na ugye ez sem jó. Van valakinek ötlete, hogy kellene ezt elegánsan megoldani, hogy a mysql ne tudja így lefogni a gépet? Esetleg indítsam nice -vel? De ez is jelenthet problémát a kiszolgálás teljesítményében, nem?
Előre is köszi!

Laci

[quote:4d99596718="lacika"]Sziasztok,

Van egy debian woody, amin fut egy mysql. Szegény mysql eléggé le van terhelve. Történt ma, hogy ~5 percig tartott, amíg be tudtam ssh -zni a szerverre. Nyomtam egy uptime -ot és ott láttam
load avarage: 205.24 174.74 183.78
Ez egy kicsit magas. Majd megnéztem melyik folyamat eszik meg ennyire a procit. Láttam, hogy a mysql. /etc/init.d/mysql restart megoldotta a problémát. De amíg ennyire nagy volt a load normál időn belül semmit nem tudott kiszolgálni a szerver. Ez baj volt sajnos. Találtam a /etc/security/limits.conf fájlt.
Gondoltam arra, hogy felveszem a következő sort:
mysql hard cpu ?
A kérdőjel helyére kellene a megengedett processzoridő percben a leírás szerint. Ide mennyit kellene írni? 2.6 GHz Intel P4 a proci. De ahogy olvasgattam a googlival talált oldalakat, számomra az jött le, hogy a háttérben futó folyamatok előbb-utóbb elérik ezt az értéket, és a processz ki lesz gyilkolva. Na ugye ez sem jó. Van valakinek ötlete, hogy kellene ezt elegánsan megoldani, hogy a mysql ne tudja így lefogni a gépet? Esetleg indítsam nice -vel? De ez is jelenthet problémát a kiszolgálás teljesítményében, nem?
Előre is köszi!

Laci

Tegyél a gépbe memóriát, ha nem segít akkor nézd meg melyik juzer használja ennyire (show full processlist) Megoldás lehet ha 4.x mysql, akkor a privilegiumoknál a queries per hour-t maximálod.

Ahogy nézegettem a dolgot a szerveren, normál működés esetén nem történik ilyen. Véleményem szerint valamiért a mysql dobott egy hátast előre és a nem normális működés miatt terhelte le ennyire a processzort. Nagyon ritkán de elő szokott fordulni (egy évben egyszer kb.). És eléggé tudják rágni a fülem, ha egy percre is kiesik a szolgáltatás (persze teljesen jogosan reklamálnak mivel fizetnek érte). Gondolkodtam még olyanban, hogy cronból nézem egy scripttel, hogy mennyire zabálja meg a provcit a mysql, és ha elér egy kritikus értéket, akkor /etc/init.d/mysql restart. De ez nem a legelegánsabb és legjobb megoldás szerintem. Inkább meg kellene előzni a problémát, mint kijavítani. És nem igen limitálhatnám a queryket órára mert ugye akkor sem szolgálná ki az adatbázis által meghajtott oldalt. Így ötlet?

[quote:5e64815701="lacika"]Ahogy nézegettem a dolgot a szerveren, normál működés esetén nem történik ilyen. Véleményem szerint valamiért a mysql dobott egy hátast előre és a nem normális működés miatt terhelte le ennyire a processzort. Nagyon ritkán de elő szokott fordulni (egy évben egyszer kb.). És eléggé tudják rágni a fülem, ha egy percre is kiesik a szolgáltatás (persze teljesen jogosan reklamálnak mivel fizetnek érte). Gondolkodtam még olyanban, hogy cronból nézem egy scripttel, hogy mennyire zabálja meg a provcit a mysql, és ha elér egy kritikus értéket, akkor /etc/init.d/mysql restart. De ez nem a legelegánsabb és legjobb megoldás szerintem. Inkább meg kellene előzni a problémát, mint kijavítani. És nem igen limitálhatnám a queryket órára mert ugye akkor sem szolgálná ki az adatbázis által meghajtott oldalt. Így ötlet?

Pedig anr leirta, hogy mi a gond, a memória fogy el, ne csak load-ot, hanem vmstat/iostat/top-ot is nézzél.

Rendben van. Tervben volt a memóriabővítés, de majd csak január első hetében. Ha az sem oldja majd meg, akkor ismét jelentkezek ezzel a problémával. Köszönöm!

[quote:f39d748543="mocsi"][quote:f39d748543="lacika"]Ahogy nézegettem a dolgot a szerveren, normál működés esetén nem történik ilyen. Véleményem szerint valamiért a mysql dobott egy hátast előre és a nem normális működés miatt terhelte le ennyire a processzort. Nagyon ritkán de elő szokott fordulni (egy évben egyszer kb.). És eléggé tudják rágni a fülem, ha egy percre is kiesik a szolgáltatás (persze teljesen jogosan reklamálnak mivel fizetnek érte). Gondolkodtam még olyanban, hogy cronból nézem egy scripttel, hogy mennyire zabálja meg a provcit a mysql, és ha elér egy kritikus értéket, akkor /etc/init.d/mysql restart. De ez nem a legelegánsabb és legjobb megoldás szerintem. Inkább meg kellene előzni a problémát, mint kijavítani. És nem igen limitálhatnám a queryket órára mert ugye akkor sem szolgálná ki az adatbázis által meghajtott oldalt. Így ötlet?

Pedig anr leirta, hogy mi a gond, a memória fogy el, ne csak load-ot, hanem vmstat/iostat/top-ot is nézzél.

andrej_ :) van anr is itt, de Ő másik emberke

[quote:acc6eba95f="lacika"]Rendben van. Tervben volt a memóriabővítés, de majd csak január első hetében. Ha az sem oldja majd meg, akkor ismét jelentkezek ezzel a problémával. Köszönöm!

Najó csak lehet, hogy a normál működéshez elég lenne a jelenlegi memória. Picit nyomozz hogy mi történik, mert az egyik oldal nálunk épp referer spam-et kap (ahogy már a hup is többször) és ez okozhat ilyesmit.

[quote:259d131c15="andrej_"]

andrej_ :) van anr is itt, de Ő másik emberke

True, true...
Rövidítek wazz. :lol: Vedd dícséretnek. :twisted:
Nekem is volt ilyen hasonlo gondom, de ott egy 1GB RAM mellett egyszer lekapcsoltam a swap-ot és elfelejtettem visszakapcsolni. :oops: Szepen ment napokig, neha hetekig, de valamiert mindig elofordult hogy szanaszet terhelte a gepet. Na mi volt a megoldas? :D

[quote:60bec818c6="andrej_"][quote:60bec818c6="lacika"]Rendben van. Tervben volt a memóriabővítés, de majd csak január első hetében. Ha az sem oldja majd meg, akkor ismét jelentkezek ezzel a problémával. Köszönöm!

Najó csak lehet, hogy a normál működéshez elég lenne a jelenlegi memória. Picit nyomozz hogy mi történik, mert az egyik oldal nálunk épp referer spam-et kap (ahogy már a hup is többször) és ez okozhat ilyesmit.

Nyomozgatok, nyomozgatok, mert azért egy picit idegesít a dolog. Csak sajnos ha beindul jövő héten a munka a kellemes pihenés után, nem lesz időm egész nap nyomozgatni :(. Gondoltam most arra, hogy használhatnám az snmp -t a processzek figyelésére, és akkor hamarabb értesülnék ha a dolgok nem úgy haladnak, ahogy ezt szeretném, nem jó ötlet?

Üdvözlet,

A téma rövid időn belül előkerült ismét sajnos :(.
Bejelentkeztem root felhasználóvan a mysql adatbázisba (mysql -p -u root). Majd kiadtam a status parancsot. Erre ezt kaptam:
Threads: 172 Questions: 2762278 Slow queries: 1 Opens: 3618 Flush tables: 1 Open tables: 505 Queries per second avg: 188.861

A szerver load avarage -ja 15-40 közöt mozog. A mysqld nice -10 -el van indítva, hogy a többi szolgáltatást (pop3,imap,smtp,ftp,ssh,dns) relatív időben ki tudja szolgálni. A gépben jelenleg 1 GB ECC memória van. Swappelni nem swappel.
A my.cnf így fest (a szükséges idézet):

nice = 10
key_buffer = 384M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
myisam_sort_buffer_size = 64M
thread_concurrency = 4
thread_cache = 8
max_allowed_packet = 1M
thread_stack = 128K
query_cache_size = 32M
thread_concurrency = 4
max_connections = 500
query_cache_type = 1

A mysql alapú oldalakat igen gyatra sebeséggel szolgálja ki. Ha nice paraméter értékét nullára állítom, akkor szintén felszökik a load avarage 40-50 környékére és elég körülményes akkor be ssh -zni, ezért van 10-en.
Lehetséges még valamit finomítani a my.cnf -en? Vagy ez a vas ennyit bír és ezt kellene esetleg bővíteni. Jelenleg 1 db Intel 4 Xeon 2.2 GHz van benne. A hyperThreading bekapcsolva és így a cat /proc/cpuinfo 2 -őt is mutat. Lehetőség van még egy fizikai proci beszerelése, és a RAM bővítése +1 GB. Megoldhatja a sebességbeli problémámat? Vagy esetleg valaki ajánlana erre egy szervert? Ha lehet kérnem ne pár millió forintosat :).
Előre is nagyon szépen küszönöm!

Laci

Megtaláltuk a "bűnöst". Az egyik php kódrészlet tartalmazott feleslegesen bonyolult sql lekéréseket. Ezt javítva, a szerver meg sem érzi a dolgot. Egy valós időben készült statisztikát generált. Ami sok felhasználó jelenlétekor nagy terheltséget okozott.

ne add fel, nekem ~100kérés van/s és egy dual p3-800 hajtja fél giga rammal és tökéletesen gyors..
szóval nemhiszem,hogy a vas lenne rossz nálad..
oprendszerrel minden oks?
tcp-n szolgál ki az sql,vagy lokálban unix socketen keresztül?

[quote:c360e95020="OxY"]ne add fel, nekem ~100kérés van/s és egy dual p3-800 hajtja fél giga rammal és tökéletesen gyors..
szóval nemhiszem,hogy a vas lenne rossz nálad..
oprendszerrel minden oks?
tcp-n szolgál ki az sql,vagy lokálban unix socketen keresztül?

Az oprendszer többi részével minden a legnagyobb rendben, ami egy up-to-date debian sarge. Az sql tcp -n és socketen is keresztül fogad kapcsolatot.
A socket gyorsabb, nem? Megnézem a terhelt oldalt, hogy tcp -n vagy socketen keresztül kapcsolódik -e.

A kérdéses oldal socketen keresztül kapcsolódik a mysql -hez php -n keresztül. Ez jobb megoldás, mint tcp -n keresztül kapcsolódna, nem?
Ja, korábban valahol mint ha olvastam volna, hogy a HyperThreading bekapcsolása rosszabb eredményeket adott, mint a HyperThreading kikapcsolása, főleg adatbázisműveleteknél? Igaz ez? Kicsit homályosak az emlékek :(.

Beszámolok a fejleményekről.
A legforgalmasabb oldalt átraktam egy másik szerverünkre. Eddig úgy fest hogy annak a szervernek meg sem kottyan a terhelés.
A "régi" szerver paraméterei:
MSI P1-1000R (nem pentium 1es :) )
http://msicomputer.co.uk/Products.aspx?product_id=703489&cat_id=79
1x256MB Ram & 1x 512 MB Ram 2,4 Intel Celeron 120 GB ATA HDD
Szoftverkörnyezet: debian Woody 2.4.32 kernel, és a disztribúcióban lévő apache, mysql és forrásból php5 (kellett az oldalhoz).
Az "új" szerver HP X4000 Workstation (2x2,2 GHz Intel Xeon (HT-vel, fizikálisan 1 Xeon cpu), 1024 MB RAMBUS, 2x250 GB WD ATA HDD mirror1, 2x18,6 GB WD SCSI mirror 1 (alaplapi Simbios Logic vezérlővel)
Szoftver: Debian Sarge 2.6.14.3-grsec kernel, disztribúcióban lévő apache2-mpm-prefork, mysql-4.0.24, php-4.3.10-16.
Ennek a szervernek nem okoz különösebb problémát. Nagyban segített a hardverbeli különbség, pedig ez a HP egy régebbi gép, de harderileg nagyságrendekkel nagyobb. Meg gondolom a szoftverkörnyezet korszerűbb mivoltából is adódik e nagyszabású teljesítménynövekedés.
Csak azért írtam, mert ha másnak is hasonló problémája lesz/van, és a "régi" szerverhez hasonlóval próbálja megoldani, megkímélheti magát és inkább a szoftverek finomhangolástól és a fejfájástól és az álmatlan éjszakáktól :).

izé... még nincs péntek ;)

btw, a backports-ról már telepíthető a mysql 5.0.18-0bpo1 sarge-ra:
[code:1:435c890294]deb http://www2.backports.org/debian/ sarge-backports main[/code:1:435c890294]

csak egy tipp (nem sokat használom egyik sql servert sem mostanság), de binary log esetleg? valahol láttam (oreilly féle LAMP siteon talán?) egy nagyon jó leírást rá, akár segíthet rajtad is.
sok sikert.

[quote:e2b92e7966="Jonci"]izé... még nincs péntek ;)

btw, a backports-ról már telepíthető a mysql 5.0.18-0bpo1 sarge-ra:
[code:1:e2b92e7966]deb http://www2.backports.org/debian/ sarge-backports main[/code:1:e2b92e7966]

Köszi az infót, de elég sok más alkamazást kellene átírnom, hogy 5ös phpvel menjen rendesen. Ha a 4es bírja, akkor marad az. De eddig a legmagasabb load 1.2 -volt a 60-70 helyett :) ~ ugyanakkora látogatottság melett :)

"Megoldottam" azzal a problémát, amíg nem lesz memória bővítés, hogy a /etc/security/limits.conf -ba felvettem ezt:
mysql hard nproc 150
www-data hard nproc 150

Így nem lesz annyi processz, hogy ezek teljesen lezabbantsák a szervert. Eddig jónak tűnik ez.

[quote:07ad8084bc="andrej_"][quote:07ad8084bc="lacika"]Rendben van. Tervben volt a memóriabővítés, de majd csak január első hetében. Ha az sem oldja majd meg, akkor ismét jelentkezek ezzel a problémával. Köszönöm!

Najó csak lehet, hogy a normál működéshez elég lenne a jelenlegi memória. Picit nyomozz hogy mi történik, mert az egyik oldal nálunk épp referer spam-et kap (ahogy már a hup is többször) és ez okozhat ilyesmit.

egy láma kérdés: mi az a referer spam???

[quote:37b9bb83a6="suti"][quote:37b9bb83a6="andrej_"][quote:37b9bb83a6="lacika"]Rendben van. Tervben volt a memóriabővítés, de majd csak január első hetében. Ha az sem oldja majd meg, akkor ismét jelentkezek ezzel a problémával. Köszönöm!

Najó csak lehet, hogy a normál működéshez elég lenne a jelenlegi memória. Picit nyomozz hogy mi történik, mert az egyik oldal nálunk épp referer spam-et kap (ahogy már a hup is többször) és ez okozhat ilyesmit.

egy láma kérdés: mi az a referer spam???

http://en.wikipedia.org/wiki/Referer_spam

Korai volt az öröm. Raktam memóriát a gépbe, igaz nem túl sokat tudtam, mert kicsit limitált ez a rack szerver bővítési kapacitása. Sokkal jobb nem lett a helyzet :(. Most azon gondolkodok, hogy lecserélném a woody -ban lévő mysql -t 5 -ös verzióra? Jelenleg 2.4 -es kernelből van fennt a legfrisebb. Cseréljem esetleg a 2.6 -os széria legfrisebbikére? Segítene az valamennyit? Jelenelg csak egy 2,4 -es Celeron van a gépben. Ahogy olvastam a gyártó oldalán, a gép elbírná a 3 GHz procit is (nem cerka). Sokban segítene a proci upgrade -je? Vagy inkább vegyek bele 2x1 GB ramot (mert többet nem lehet bele gyömöszkölni), jelenleg 1x512 MB & 1x256 MB van benne.? Tehát mi az a bővítési/fejlesztési irány ami a legnagyobb mértékben segítene? Az hogy vegyek egy 8 procis Opteron szervert, az sajna kilőve :). Előre is köszönöm!

[quote:3af12d994c="lacika"][quote:3af12d994c="Jonci"]izé... még nincs péntek ;)

btw, a backports-ról már telepíthető a mysql 5.0.18-0bpo1 sarge-ra:
[code:1:3af12d994c]deb http://www2.backports.org/debian/ sarge-backports main[/code:1:3af12d994c]

Köszi az infót, de elég sok más alkamazást kellene átírnom, hogy 5ös phpvel menjen rendesen. Ha a 4es bírja, akkor marad az. De eddig a legmagasabb load 1.2 -volt a 60-70 helyett :) ~ ugyanakkora látogatottság melett :)

öööizé, én mysql-ről beszéltem és nem php-ről ;)

nem olvastam még a mysql 4.x és az 5.x közötti sebesség különségről, vagy a "miben jobb az 5.x a 4.x-nél"-t, csak gondoltam, jelzem, ha azt szeretnéd használni, könnyen fel tudod tenni

[quote:ec0ddb9816="Jonci"][quote:ec0ddb9816="lacika"][quote:ec0ddb9816="Jonci"]izé... még nincs péntek ;)

btw, a backports-ról már telepíthető a mysql 5.0.18-0bpo1 sarge-ra:
[code:1:ec0ddb9816]deb http://www2.backports.org/debian/ sarge-backports main[/code:1:ec0ddb9816]

Köszi az infót, de elég sok más alkamazást kellene átírnom, hogy 5ös phpvel menjen rendesen. Ha a 4es bírja, akkor marad az. De eddig a legmagasabb load 1.2 -volt a 60-70 helyett :) ~ ugyanakkora látogatottság melett :)

öööizé, én mysql-ről beszéltem és nem php-ről ;)

Igen, most nézem, csak már elég fáradt voltam :) Én is a mysql5 -re gondoltam, nem a php5 -re. De ha mysql 5 -öt szeretnék, akkor migrálni kellene az összes adatbázist a,i a szerveren van a mysql.com oldalán lévő migration tool -lal, nem? Az meg nagy meló lenne, mert sok adatbázis van.
Érdemes lenne? Próbáltad már az 5ös mysqlt?

[quote:d7de8b834b="Jonci"]monit - http://www.tildeslash.com/monit/
nezd meg, hasznos tud lenni

Megnéztem az oldalt. Igen, igazad van, hasznos tud lenni ez a project. de nekem ez most nem oldja meg a problémámat sajnos :(.

[quote:27ac39d9ff="lacika"]Érdemes lenne? Próbáltad már az 5ös mysqlt?

valszeg az alatt szerkesztettem a hozzászólásomat, mialatt írtad ezt

[quote:69c44d8729="lacika"]/etc/init.d/mysql restart megoldotta a problémát.

erre írtam, ezt helyetted a monit automatikusan meg tudja csinalni,
ha egy program valamiért elkezdené zabálni a memóriát és/vagy procit stb. akkor újraindítja, hátha segít, de mail-t is tudsz vele küldenit, hogy baj van (pl telefonra, stb)