Serverload verminderen dmv aanpassingen aan configs etc?

[Verwijderd]

Hallo,

Is het mogelijk om de serverload te minderen van mijn server?
Ik zal even specs geven van de server.

Specs:
Processors 2
Model Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
Chip MHz 2128.06 MHz
Buffergrootte 2048 KB
Systeem Bogomips 8515.83


Geheugengebruik:
Type Percentage gebruikt Vrij Gebruikt Grootte
Fysiek geheugen 79% 211.88 MB 799.38 MB 1011.25 MB
Swap geheugen 0% 2.52 GB 6.29 MB 2.53 GB

In de normale tijden is de load tussen de 1.00 en de 3/4.00 veels te hoog dus!
Als het uur valt (12:00, 13:00 etc) komen er veel mensen op de site om te attacken etc.

En dan kan de load omhoog schieten tot 8/9/10.00! VEELS TE VEEL DUS!
Scripting is al geoptimaliseerd en database indexen ook al toegepast.

Huidige serverload: Gemiddelde belasting 5.82 7.07 5.78
Dit met 290 leden online

Ik weet niet of het van belang is als ik de website erbij post maar dat doe ik nog niet omdat het anders als spam kan worden opgevat.

Mijn settings in httpd.conf:

Timeout 60
KeepAlive Off
MaxKeepAliveRequests 30
KeepAliveTimeout Off
MinSpareServers 10
MaxSpareServers 64
StartServers 10
MaxClients 2500
MaxRequestsPerChild 0

Wat dingen uit my.cnf:

[mysqld]
#datadir=/var/lib/mysql
#socket=/var/lib/mysql/mysql.sock
skip-locking
skip-innodb
query_cache_limit=1M
query_cache_size=32M
query_cache_type=1
max_connections=500
interactive_timeout=100
wait_timeout=100
connect_timeout=10
thread_cache_size=64
key_buffer=16M
join_buffer=1M
max_allowed_packet=16M
table_cache=1024
record_buffer=1M
sort_buffer_size=2M

Wat kan ik nog doen en veranderen aan deze settings zodat de load minder word?
Oja gegevens van phpmyadmin:

Totaal ø per uur ø per minuut ø per seconde
1.389 k 1,53 M 25,56 k 425,95

Mvg
Bulletstar

[CyBeR]

Gebruik je php? Heb je een opcode cache geinstalleerd? Probeer eAccelerator.

[Verwijderd]

Ik gebruik PHP ja (PHP 5.2.1), Ik heb een dedicated server en de mensen zeggen waar ik hem huur dat eAccelerator niet goed draaid met de andere gegevens die op de server draaien zoals PHP5, DirectAdmin etc.

Mvg
Bulletstar

[RobIII]

Als je de load wil verminderen zul je eerst moeten uitzoeken waar de load in zit; welk proces veroorzaakt het probleem? Probeer eens met wat performance monitors (of simpelweg het taakbeheer) uit te zoeken wat de oorzaak precies is. In het wilde weg allerlei oplossingen proberen of installeren schiet natuurlijk niet op en is hetzelfde als geblinddoekt kleiduif schieten

[Verwijderd]

Je zult toch echt wat statistieken moeten verzamelen om te kunnen bepalen waaraan je iets moet gaan doen. Hoe weet je dat er op hele uren meer bezoekers komen? Dat de load dan toeneemt kan net zo goed zijn doordat er access logs worden verwerkt of iets dergelijks. Of is er een bepaalde reden dat je website net na het hele uur interessanter is? Post eens een overzichtje van alle cronjobs die je hebt?

De bottleneck kan bij performance problemen lastig te vinden zijn. Alles gaat trager, alles lijkt een oorzaak te zijn. Het kan bij wijze van spreken ook gewoon teveel disk I/O zijn, traag geheugen, zware belasting door een spam/virusfilter, etcetera. Zoek niet direct in Apache of MySQL. Probeer eerst eens om die uit te schakelen, en te kijken wat er dan met de load gebeurt.

[Verwijderd]

Alle mysql processen,

Overigens raar voorval: ik gebruik mysql_connect() en ook sluit ik extra nog alles met mysql_close();
En dan doe ik via ssh de command:

meleagant:~# ps aux | grep -c mysqld
69

69 wel erg veel open connecties ..

[Gwaihir]

Mocht het uitindelijk (o.a.) opcode cache worden: eAccelerator *zou* tegenwoordig met PHP5 samen moeten werken, maar APC doet dat zeker en lijkt ondertussen meer gebruikt.

[Verwijderd]

69 is veel open connecties, maar zoals ik al zei, op een gegeven moment kun je overal wel het probleem in gaan zien. Allerlei dingen gaan traag, en worden daardoor verdachten. Heel soms is het juist een ogenschijnlijk onschuldig proces dat de boel vertraagt. Een load van boven 1.00 wil niet direct zeggen dat je processor het niet bij kan benen. Het kan ook iets heel anders zijn, maar het systeem kan het niet bijbenen. En dat kan dus door vanalles komen.

[Verwijderd]

Maar het leuke is, ik heb werkelijk OVERAL op de GEHELE server mysql_close();

bovendien gebruik ik in elke config alsnog mysql_connect ..

Mvg
Bulletstar

[Gwaihir]

What zegt MySQL zelf daarvan? (SHOW PROCESSLIST, bijvoorbeeld vanuit phpMyAdmin)

[Verwijderd]

Ik doe deze command:


meleagant:~# ps aux | grep -c mysqld
69

----

SQL-query:
SHOW PROCESSLIST

Id User Host db Command Time State Info
stop proces 902979 admin_server localhost admin_server Query 0 Locked UPDATE `[users]` SET `cash`=`cash`+'9.67232250788E...
stop proces 903020 admin_server localhost admin_server Query 0 Locked SELECT id FROM `[users]` WHERE (UNIX_TIMESTAMP(NOW...
stop proces 903027 admin_server localhost admin_server Query 0 Locked SELECT `clicks`,`power`,`lastattack`,`familie`,`ca...
stop proces 903081 admin_server localhost admin_server Query 0 Sending data SELECT * FROM `[users]`
stop proces 903085 admin_server localhost admin_server Query 0 Locked UPDATE `[users]` SET `rankvord`=`rankvord`+'1',`wa...
stop proces 903088 admin_server localhost admin_server Query 0 Writing to net SELECT * FROM `[users]`
stop proces 903089 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903099 admin_server localhost admin_server Query 0 Writing to net SELECT * FROM `[users]`
stop proces 903100 admin_server localhost admin_server Query 0 Locked UPDATE `[users]` SET `rankvord`=`rankvord`+'0.25',...
stop proces 903101 admin_server localhost admin_server Query 0 Locked UPDATE `[users]` SET `cash`=`cash`-'3.44297530139E...
stop proces 903106 admin_server localhost admin_server Query 0 Locked SELECT `login`,`power`,`clicks`,`maffiamode`,`cash...
stop proces 903116 admin_server localhost admin_server Query 0 Locked SELECT `clicks`,`power`,`lastattack`,`familie`,`ca...
stop proces 903117 admin_server localhost admin_server Query 0 Locked SELECT `lastkill`,`kogelsgekocht`,`login`, `maffia...
stop proces 903115 admin_server localhost admin_server Query 0 Locked SELECT * FROM `[users]`
stop proces 903114 admin_server localhost admin_server Query 0 Locked SELECT `clicks`,`power`,`lastattack`,`familie`,`ca...
stop proces 903132 admin_server localhost admin_server Query 0 Locked SELECT `clicks`,`power`,`lastattack`,`familie`,`ca...
stop proces 903135 admin_server localhost admin_server Query 0 Locked SELECT `clicks`,`power`,`lastattack`,`familie`,`ca...
stop proces 903146 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903153 admin_server localhost admin_server Query 0 Locked SELECT * FROM `[users]` WHERE login='klitje'
stop proces 903152 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903156 admin_server localhost admin_server Query 0 Locked SELECT * FROM `[users]` WHERE login='schadowfax'
stop proces 903184 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903186 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903185 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903188 admin_server localhost admin_server Query 0 NULL SHOW PROCESSLIST
stop proces 903195 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903196 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903209 admin_server localhost admin_server Query 0 Locked SELECT login, `hash`, level, vermoord,rank, famili...
stop proces 903210 admin_server localhost admin_server Sleep 0 NULL

[AndriesLouw]

Probeer eens bepaalde pagina's die niet veel veranderen eens te cachen, door ze bijvoorbeeld 1 maal per half uur te genereren, en op te slaan als .html bestand, dit zou je goed kunnen doen met bijvoorbeeld ledenlijsten.

Edit:
Of wat ik ook wel veel zie is dat er in een sessie wordt opgeslagen dat een lid niet meer dan (bijv.) 30 pageviews per minuut mag genereren, zo kun je de load verminderen.

[ Voor 30% gewijzigd door AndriesLouw op 02-07-2007 19:07 ]

[Verwijderd]

Dat doe ik al bij stats, en bij familie lijst.
Bij de ledenlijst is dit onmogelijk omdat mijn leden daar kijken wie het meeste geld heeft en dit MOET realtime!

[AndriesLouw]

Daarvoor zou je top 10's kunnen maken, of alleen een lijst met id, naam, geld. De volgende query zou eigenlijk niet mogen: "SELECT * FROM `[users]`", ik zie deze een paar keer voorbij komen in je processenlijst, en deze query haalt alle gegevens op, van alle users, wat dus wel eens even kan duren. Je zou kunnen overwegen deze pagina eens per 30/60 seconden te genereren.

Edit:
Iemand misschien een idee of hij ook MySQL caching kan gebruiken?

[ Voor 10% gewijzigd door AndriesLouw op 02-07-2007 19:12 ]

[Verwijderd]

Dat van ledenlijst gaan ze echt haten en dan verlies ik echt 100den vaste leden..
Ik ga wel kijken waar die * vandaan komt, aangezien dat niet kan he

[Gomez12]

Verwijderd schreef op maandag 02 juli 2007 @ 19:06:
Dat doe ik al bij stats, en bij familie lijst.
Bij de ledenlijst is dit onmogelijk omdat mijn leden daar kijken wie het meeste geld heeft en dit MOET realtime!

Ach tja, moeten moeten... Hoeveel personen bekijken dit tegelijkertijd en F5én dit alleen maar???

Als het een echte volle site is dan zou je zelfs al veel bereiken met caching van 1 sec. Maar praktisch gezien zou ik waarschijnlijk gewoon 1x per 5 sec cachen. Is voor de meeste mensen realtime genoeg ( Want ze zijn 5 sec bezig met zoeken naar users en gegevens lezen ).

Familie lijst zou ik werken met een oneindige cache die gewoon invalidated wordt als iemand een nieuw familie lid plaatst, stats 1x per half uur verwerken.

Plus wat je eens zou kunnen nakijken is of er geen andere processen op je server zijn die veel per uur doen ( weet niet of DA dit doet ) zoals logs parsen etc.

[Verwijderd]

Ik heb 4 SLOW QUERYS zie ik, iemand ervaring hoe ik een log bestand online kan zetten?

[_Apache_]

69 connecties open is toch niet veel met....

Dit met 290 leden online

[ Voor 16% gewijzigd door _Apache_ op 02-07-2007 19:31 ]

[Verwijderd]

Een andere soortgelijke site heeft met 400 leden online maar 15

[_Apache_]

Verwijderd schreef op maandag 02 juli 2007 @ 19:32:
Een andere soortgelijke site heeft met 400 leden online maar 15

Aah ok, jij zegt het, het leek me niet veel, maar dan heb k weer ook niet veel verstand van sites op deze schaal..

[Verwijderd]

Ik dacht zelf ook dat het niet veel was totdat ik het resultaat bij hem zag, scripting verschilt weinig tot niks..

Dus vandaar zo'n raar probleem


edit:

Gemiddelde belasting: 1.48 2.12 2.74, word al beter gelukkig..

Vraagje aan alle guru's hier, voor mijn ledenlijst gebruik ik een class, is het misschien slimmer om een makkelijke ledenlijst te maken zonder class???

[ Voor 44% gewijzigd door Verwijderd op 02-07-2007 19:53 ]

[CyBeR]

Birdie schreef op maandag 02 juli 2007 @ 18:49:
Mocht het uitindelijk (o.a.) opcode cache worden: eAccelerator *zou* tegenwoordig met PHP5 samen moeten werken, maar APC doet dat zeker en lijkt ondertussen meer gebruikt.

eAccelerator werkt prima met PHP5. Ik gebruik 't alleen als opcode cache in shmem, niet als optimizer.

APC heb ik juist minder goede ervaringen mee. Dat was veel minder stabiel. (Maar test 't toch allebei, 't kan zomaar iets geweest zijn wat alleen bij onze code de fout in ging, of inmiddels al gewoon gefixed.)

Oh en of jij 69 connecties hebt en iemand anders maar 15 maakt niet uit. Hij kan net zo goed pconnects gebruiken en 15 apache workers hebben.

[ Voor 10% gewijzigd door CyBeR op 02-07-2007 19:57 ]

[Verwijderd]

Oke bedankt CyBeR
Ik ga vandaag nog ff lekker de scripting doorneuzen, en een ledenlijst (simpel, geen class) erop zetten.. kijken of dat helpt..

En kijken waar SELECT * FROM [users] word gedaan etc

[ACM]

Misschien moet je eens kijken waarom al die queries locked zijn en of dat komt omdat er een of enkele nogal traag op die data werken. Je hebt natuurlijk de benodigde indexen geplaatst, o.a. op dat login-veld van die user-tabel?
En als je inderdaad de benodigde indexen hebt kan het zijn dat je gewoon te veel gelijktijdige gebruikers erop hebt en dat je moet uitwijken van myisam naar innodb ivm de betere lockingsmogelijkheden.

Als de tabellen een beetje fors zijn heb je ook kans dat een key_buffer van 16MB niet meer voldoet, phpmyadmin toont allerlei interessante statistieken over het gebruik van die en andere zaken.

[Verwijderd]

Wat bedoel je met forse tabellen? crons onderhouden mij database wel goed en logs worden om de xx uur gedelete dus database is altijd tussen de 50/100MB

Kan ik zonder problemen veranderen van Mysam naar nnodb ?

[ACM]

Verwijderd schreef op maandag 02 juli 2007 @ 20:16:
Wat bedoel je met forse tabellen? crons onderhouden mij database wel goed en logs worden om de xx uur gedelete dus database is altijd tussen de 50/100MB

Sja, fors is relatief Maar als je (dit is een voorbeeld) 100MB aan indexen zou hebben en maar 16MB aan buffer ervoor, dan kan dat problemen opleveren. In jouw geval zal het wat minder uitmaken denk ik.

Kan ik zonder problemen veranderen van Mysam naar nnodb ?

In principe wel, mits je database innodb-ondersteuning heeft (wat al tijden standaard is) en je innodb-files hebt (wat ook al tijden standaard aangemaakt wordt) en mits je geen gebruik maakt van specifieke myisam-only-constructies (wat er vrij weinig zijn, maar met full text index als belangrijkste).
Je zal even hebben dat de tabellen onbruikbaar zijn, maar met zo'n kleine database zou dat secondenwerk moeten zijn, eventueel zou je je apache tijdelijk uit kunnen schakelen net voor je het doet of een of andere maintenancemelding terug kunnen geven.

Maar voor je dat doet kan je beter beoordelen of je tabellen wel goed geconstrueerd zijn, want innodb is geen magisch middel waarvan alles ineens beter gaat

[Gomez12]

Verwijderd schreef op maandag 02 juli 2007 @ 20:16:
Wat bedoel je met forse tabellen? crons onderhouden mij database wel goed en logs worden om de xx uur gedelete dus database is altijd tussen de 50/100MB

Kan ik zonder problemen veranderen van Mysam naar nnodb ?

Ff een vraagje, met een dbase van max 100MB dat moet makkelijk in je geheugen passen dus zou ik toch maar eerst eens kijken naar optimalisaties ( en wat er verder nog op de server draait ) want een dbase van 100MB die langzaam loopt bij 1024MB geheugen vind ik persoonlijk wel een beetje raar en ik vermoed ook dat of je 100MB niet klopt of dat je veel en veel te indexen hebt staan ( alhoewel 900MB aan indexen??? )

Verwijderd schreef op maandag 02 juli 2007 @ 20:16:
...
Kan ik zonder problemen veranderen van Mysam naar innodb ?

Zoals acm al zegt waarschijnlijk wel, maar op een dbase van 100MB verwacht ik eerder dat innodb langzamer gaat lopen dan sneller ( omdat ik het zeer onwaarschijnlijk acht dat je echt de features gebruikt die het sneller maken ).

Ik zou als ik jouw was toch nog maar eens gaan kijken naar optimalisaties, want volgens mij doe je ergens iets grondigs fout.

P.S. Hoe is die 290 leden online berekend, is dit 290 concurrent webrequests of 290 sessies die nog niet verlopen zijn?

[ Voor 30% gewijzigd door Gomez12 op 02-07-2007 20:50 ]

[Verwijderd]

Als ik mijn database een week niet leeg kwa crons, is deze al snel +900 MB misschien wel dubbel..


@P.S. Hoe is die 290 leden online berekend, is dit 290 concurrent webrequests of 290 sessies die nog niet verlopen zijn?


Leden online in de laatste 3 minuten (als je een pagina hebt bezocht)

[ Voor 50% gewijzigd door Verwijderd op 02-07-2007 21:00 ]

[Gomez12]

Verwijderd schreef op maandag 02 juli 2007 @ 20:52:
Als ik mijn database een week niet leeg kwa crons, is deze al snel +900 MB misschien wel dubbel..

WTF doe je in je crons??? Want eventjes 8/9e per week weggooien vanuit je dbase vind ik wel erg veel?
Of je logt extreem veel met een zeer korte verlooptijd ( waarom dan zo veel loggen ) of je gooit ergens gewoon gegevens weg...

@P.S. Hoe is die 290 leden online berekend, is dit 290 concurrent webrequests of 290 sessies die nog niet verlopen zijn?


Leden online in de laatste 3 minuten (als je een pagina hebt bezocht)

Dus oftewel aantal pagerequests is onbekend? Want 1 lid kan wel 100 page requests doen in 3 min.

En met een gemiddelde php-parsetijd van 0,1 sec ( eigen hoog afgerond genomen gemiddelde ) zou je zelfs zonder caching nog niet direct in de problemen moeten komen bij 8 requests per sec ( oftewel 1440 requests per 3 minuten, oftewel 4 pagina's bekeken per lid per 3 minuten )

Maar ik krijg meer en meer het idee dat er ergens 1 pagina staat ( bijv ledenlijst ) die erg zwaar is en waar je een paar mensen hebt die de hele tijd zitten te F5'en. Dus ga eens benchmarken ( hoelang doet je meestgevraagde pagina over het parsen, daarna je 2e pagina etc ) en ga dan eens kijken of je niet ergens caching in kan bouwen dit hoeft btw niet de hele pagina te zijn, als vb de trackers van tweakers daaar geloof ik van dat GoT een refresh tijd heeft / had van 1 minuut. Puur omdat mensen op de FP gemiddeld langer dan 1 min doen over het lezen van 1 artikel.
Dus gewoon per deel/ query cachen en kijken hoe groot de reeele kans is dat mensen het willen hebben dat het veranderd ( vb. bij een webshop die ik ooit eens gemaakt heb zat een stuk aanverwante artikelen als je detailinfo van een artikel opzocht, eerst was de aanverwante artikelen 100% dynamisch, omdat de mensen dit onrustig vonden maar een caching ingebouwd van 6 uur, toen ging ineens de load omlaag van 0,6 naar 0,1., Oftewel tevredener gebruikers en de tevredener webserver, iedereen tevredener dus )

[AndriesLouw]

Het lijkt mij inderdaad slim om eens je database te normaliseren, en opnieuw te ontwerpen. Probeer dan ook niet nuttige informatie, die wel veel resources "eten" weg te laten (dus niet op te slaan), hiermee doel ik vooral op gebruikers statistieken, zoals het loggen van elke pageview.

Ga daarna eens je code optimaliseren of herschrijven aan de hand van de nieuw ontworpen database, en kijk daarbij ook waar je het beste caching kunt toepassen, het kost misschien wat tijd, maar daarvoor krijgen je bezoekers een hoop terug.

[Verwijderd]

Heb de ledenlijst even herschreven, en met succes..
Eergisteren was load tijdens attack met maar 40 leden online +- 3.00, nu was de piek 0.40 , en er zal nog veel meer te verbetere zijn denk ik..

nu: Gemiddelde belasting 0.20 0.18 0.23

[Gwaihir]

Heb je nu ook veel minder queries in LOCKED staan (en daardoor minder in totaal)? Zijn er nog steeds relatief veel gelocked, dan zou ik daar de reden van gaan opsporen.

[igmar]

Verwijderd schreef op maandag 02 juli 2007 @ 19:01:
Id User Host db Command Time State Info
stop proces 902979 admin_server localhost admin_server Query 0 Locked UPDATE `[users]` SET `cash`=`cash`+'9.67232250788E...
stop proces 903020 admin_server localhost admin_server Query 0 Locked SELECT id FROM `[users]` WHERE (UNIX_TIMESTAMP(NOW...
stop proces 903027 admin_server localhost admin_server Query 0 Locked SELECT `clicks`,`power`,`lastattack`,`familie`,`ca...

Begin eens met kijken of je echt MyISAM nodig hebt. Veel concurrent updates + veel leesacties zijn niet bepaald fijn met myISAM.