PDA

Bekijk Volledige Versie : [Nogmaals]Hoge CPU Load apache en mysql lopen vast



Arto
18/08/06, 17:19
Beste,

Ik heb al een heel lang tijd grote problemen met mijn dedicated server.
Ik zal wat kort informatie geven over het server :

Os : CentOs 4.3
Direct Admin

Zelf geinstallleerde software :
*RKHunter
*Chkrootkit-0.46a
*APF Firewall 0.9.6-1
*BFD-0.9 [ Brute Force Detection ]
*Shoutcast
*MRTG


Processor Name Mobile AMD Sempron(tm) Processor 3100+
Vendor ID AuthenticAMD
Processor Speed (MHz) 1800.342
Total Memory 499796 kB
Free Memory 10680 kB
Total Swap Memory 1052248 kB
Free Swap Memory 1004880 kB
Apache 1.3.37
DirectAdmin 1.27.4
Exim 4.60
MySQL 4.1.11
Named 9.2.4
ProFTPd 1.2.10
sshd
vm-Pop3d 1.1.7f-DA-2


Ik heb 12 maanden zelfde klanten op een Dell Poweredge server gehad, nooit problemen gehad.
Maar met deze server{Leasweb} heb ik flinke problemen.
Dus het is niet zo dat ik ontiegelijk veel klanten host ofzo.

Het probleem is dat apache een heel hoge CPU load heeft en MysQL ook.
Heel vaak lopen deze twee proccessen helemaal vast en moet ik ze restarten via SSH.
Ik heb alle logfiles doorgelezen in /var/log maar niks bijzonders.
Gemiddeld zo'n 2 tot 3 uur loopt Apache en MysQL vast.
Soms wel telkens, dus als ik hem restart gaat ie gewoon verder met hoge load.

Ik heb het httpd.conf file aangepast, KeepAlive Off i.p.v On
Toen was het een beetje opgelost maar later begon het allemaal weer helaas.

Hierbij mijn httpd.conf en my.cnf :

httpd.conf
===========
Timeout 300
KeepAlive Off
#MaxKeepAliveRequests 500
#KeepAliveTimeout 5
MinSpareServers 5
MaxSpareServers 20
StartServers 8
MaxClients 450
MaxRequestsPerChild 1000

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=1500
interactive_timeout=100
wait_timeout=15
connect_timeout=10
thread_cache_size=128
key_buffer=16M
join_buffer=1M
max_allowed_packet=16M
table_cache=1024
record_buffer=1M
sort_buffer_size=2M
read_buffer_size=2M
bind-address = 127.0.0.1
max_connect_errors=999999999
# Try number of CPU's*2 for thread_concurrency
thread_concurrency=2
myisam_sort_buffer_size=64M
log-bin
server-id=1

Het CPU load was net nog 76,7 %
Zie bijlage :


Ik hoop dat jullie mij kunnen helpen met dit grote probleem.
Groetjes.

WilloW
18/08/06, 17:27
Het plaatje wat je post is niet zo spannend. wat host je er allemaal op ? Zou het niet gewoon zijn dat die AMD het gewoon niet trekt op de piek momenten?

Aangezien je zegt dat het op een Dell server wel goed ging en daar hangt toch meestal iets anders in kwa hardware

dreamhost_nl
18/08/06, 17:36
Ik ben het met de vorige poster eens. Hoogstwaarschijnlijk zat er in de Dell een volwaardige Intel Pentium IV en die zijn nu eenmaal iets krachtiger dan een AMD Sempron, die qua prestaties meer kan worden vergeleken met een Intel Celeron.

Wat geeft de volgende output weer?


ps aux

It-Biz
18/08/06, 17:38
max_connections=1500, kan die server zowiezo niet aan.

max_user_connections zou ik aanzetten, zodat niet 1 user alle connections gerbruikt.

almar
18/08/06, 17:42
Apache loopt vast omdat MySQL vast loopt...

Even tabellen checken en je key buffer vergroten naar 32 M.

Radi
18/08/06, 18:03
Jongens, het heeft niks met de processor te maken. Je moet aan leaseweb netjes vragen of ze jou geheugen willen upgraden naar 1024mb ipv 512mb. dit lost het probleem op. Er zijn een aantal sites die je host die gebruik maken van een database en een database server vind het leuk om veel geheugen te gebruiken en als de geheugen er niet zijn, dan loopt de load hoog op en begint ie te crashen.

WilloW
18/08/06, 22:25
Jongens, het heeft niks met de processor te maken. Je moet aan leaseweb netjes vragen of ze jou geheugen willen upgraden naar 1024mb ipv 512mb. dit lost het probleem op. Er zijn een aantal sites die je host die gebruik maken van een database en een database server vind het leuk om veel geheugen te gebruiken en als de geheugen er niet zijn, dan loopt de load hoog op en begint ie te crashen.


Ah de specialist :)

crazycoder
18/08/06, 22:30
Ah de specialist :)
Ja. En hij wil niet weten wat voor heavy sites ik laat draaien op exact evenveel geheugen. :) CPU zal ik dan maar niet noemen.... ik zeg niet dat meer geheugen verkeerd is hoor.... maar....

Er was iets met een wat oudere versie van mysql die under attack dit soort gedrag vertoonde, weet zo snel geen details.. Dus mogelijk zou upgraden helpen.

Verder de firewall goed configureren.

Helpt dat nog niet dan is er wellicht een site die dit veroorzaakt. Simpele manier om het uit te vissen:
alles uitschakelen en vervolgens na enige tijd een ander account aanzetten totdat je de oorzaak heb gevonden.

Digiover
19/08/06, 00:27
max_connect_errors=999999999
Persoonlijk vind ik dit een hele gevaarlijke instelling, daar ontzettend veel (tegelijktijdige) foutieve connecties je server best down kunnen brengen. Soort van DoS.
Zet deze waarde bijvoorbeeld op 50 of zo.

Verder komen je my.cnf waardes niet overeen met je hoeveelheid RAM. MySQL betekent afstellen, finetunen.
Voor de zoveelste maal:
key_buffer_size + (record_buffer + sort_buffer) * max_connections = ... MB
In jouw geval:
16 + (1 + 2) * 1500 = 4516 MB
Dit geeft foutmeldingen die je in je hostnaam.err logfiles terug moet kunnen vinden.

klasje.be
19/08/06, 20:59
En installeer mytop op je pc.
Deze laat je duidelijk zien welke query's hoeveel gebruiken en welke user.
Je ziet er oa key efficiëncy.

Welk is de grootste/zwaarste site die je host?
Host je bv:
- criminals sources?
- webcommunity's (scripting sites)
Sommige van deze scripts zijn echt slecht geschreven en kunnen gemakkelijk beter en efficiënter werken. Als je op uw server 30 criminalssites draait, kan het inderdaad al wel voorkomen dat hij crasht... :-p (Ps: niet alle criminals zijn slecht, 10% is wel goed :-p )

En verder kan je server vast wel wat meer RAM verdragen.

Arto
20/08/06, 18:41
Apache loopt vast omdat MySQL vast loopt...

Even tabellen checken en je key buffer vergroten naar 32 M.


Almar@,

Heb ik gedaan...probleem blijft voortdoen.




Welk is de grootste/zwaarste site die je host?
Host je bv:
- criminals sources?
- webcommunity's (scripting sites)
Sommige van deze scripts zijn echt slecht geschreven en kunnen gemakkelijk beter en efficiënter werken. Als je op uw server 30 criminalssites draait, kan het inderdaad al wel voorkomen dat hij crasht... :-p (Ps: niet alle criminals zijn slecht, 10% is wel goed :-p )


@klasje.be,

IK heb ongeveer 15 klanten die php forum gebruiken.
Zoals Invision Power Board en PhpBB.
Nooit problemen gehad zoals eerder vermeld.

IT-worX
20/08/06, 19:03
Over "goede" criminals gesproken...Waar vind je die?
Mn broer wilt dit ook draaien op mn server maar toch wel wat schrik voor :s

It-Biz
20/08/06, 19:55
IK heb ongeveer 15 klanten die php forum gebruiken.
Zoals Invision Power Board en PhpBB.
Nooit problemen gehad zoals eerder vermeld.

Kan natuurlijk zijn dat de sites nu veel meer bezoekers trekken dan voorheen, beetje moeilijk vergelijken.

Ga eerst eens kijken wat mysql daadwerkelijk gebruikt, aan keybuffer, connections etc, voor zomaar blind wat settings in te stellen.

Zoals Digiover post zou je server min 4 GB ram moeten hebben met de settings die je gebruikt...wellicht vragen om problemen?????

klasje.be
20/08/06, 19:58
Wij hosten momenteel 28 games, allemaal criminals varianten.
Eventueel mag je broer ook altijd bij ons komen (www.gamecoll.com, pb maar).
Wij voeren regelmatig scripting controles uit om te controleren of de webmasters van de games wel degelijk scripten op de manier die wij hen opdragen. Verder hebben wij ook een standaard bugloze criminals gemaakt die al iets beter draait dan de originele.
"vinden" doe je een goede criminals niet, die moet je zelf maken.
Ik heb nog geen enkele source tegengekomen die wel goed is. (www.webscripters.be => scripting community van me)
www.war4europe.com is mijn criminals, die is zwaar herscript en draait tegen zo goed als geen load (0.01) (is nu wel minder actief dan vroeger).

@Arto: IPB heeft standaard caching aanstaan, op 1 van onze servers gaf dit ook problemen aangezien deze caching veel te zwaar werd. IPB heeft toen ons script aangepast om de caching uit te zetten en nu draait dat wel vlot.
Contacteer mij maar, dan kijk ik ff hoe je dat weer kon uitzetten.