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 :).
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
[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 :).
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
[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?
- A hozzászóláshoz be kell jelentkezni
"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
- A hozzászóláshoz be kell jelentkezni
[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?
- A hozzászóláshoz be kell jelentkezni
[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
- A hozzászóláshoz be kell jelentkezni
[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!
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
[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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
[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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
[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
- A hozzászóláshoz be kell jelentkezni
[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.
- A hozzászóláshoz be kell jelentkezni
[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
- A hozzászóláshoz be kell jelentkezni
[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?
- A hozzászóláshoz be kell jelentkezni
Ü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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
[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 hozzászóláshoz be kell jelentkezni
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 :(.
- A hozzászóláshoz be kell jelentkezni
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 :).
- A hozzászóláshoz be kell jelentkezni
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]
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
[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 :)
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
[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???
- A hozzászóláshoz be kell jelentkezni
[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
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
monit - http://www.tildeslash.com/monit/
nezd meg, hasznos tud lenni
- A hozzászóláshoz be kell jelentkezni
[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
- A hozzászóláshoz be kell jelentkezni
[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?
- A hozzászóláshoz be kell jelentkezni
[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 :(.
- A hozzászóláshoz be kell jelentkezni
[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
- A hozzászóláshoz be kell jelentkezni
[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)
- A hozzászóláshoz be kell jelentkezni