Extreme Überlastung

[fulltilt]

Habe seit einigen Tagen Probleme mit extremer Load bei grösseren Datenbank Abfragen über PHP (shops, dating sites), hierbei steigt auch die Anzahl der laufenden Prozesse auf 20 - 70 und die CPU Load zieht bis 12 hoch.
Die Gesamtgrösse der DB liegt bei 1,1 GB, AMD 64 Processor 3700+, 2048 MB Ram.
Habe schon mit tuning-primer versucht zu optimieren, die Load ging nur geringfügig runter.
Was kann ich tun um das das Loadproblem in den Griff bekommen?
Hier einige Infos:

Code: Select all

top - 15:07:35 up 3 days, 11:07,  1 user,  load average: 0.70, 1.03, 1.18
Tasks: 291 total,   1 running, 290 sleeping,   0 stopped,   0 zombie
Cpu(s): 18.3%us,  7.7%sy,  0.7%ni, 68.8%id,  4.1%wa,  0.1%hi,  0.3%si,  0.0%st
Mem:   2010660k total,  1939040k used,    71620k free,    97456k buffers
Swap:  3943948k total,   131820k used,  3812128k free,   616272k cached

my.cnf

Code: Select all

skip-external-locking
skip_name_resolve
skip_locking 
key_buffer		= 32M
join_buffer_size        = 2M
sort_buffer             = 2M
read_buffer_size        = 2M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size = 64M
max_allowed_packet	= 32M
thread_stack		= 128K
thread_cache_size	= 16
max_connections         = 100
table_cache            = 13000
thread_concurrency     = 16
max_heap_table_size       = 64M 
tmp_table_size            = 64M
open_files_limit          = 32000
query_cache_type                = 1
query_cache_size                = 128M
query_cache_limit               = 16M
max_connect_errors        = 10
log_warnings              = 2
long_query_time           = 3
log_slow_queries          = /var/log/mysql/mysql-slow.log
log_queries_not_using_indexes
skip-bdb
[mysqldump]
quick
quote-names
max_allowed_packet	= 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer_size       = 128M
[myisamchk]
key_buffer_size       = 128M

myisam_repair_threads           = 1
myisam_recover = FORCE,BACKUP
[mysqlhotcopy]
interactive-timeout

[fulltilt]

Danke - könnte die Erhöhung der join_buffer_size noch etwas bringen?

slow-query log answerfen, mit


mysql> show full processlist;

prüfen welche ProZesse da laufenn und mit explain <processid> sich mal explizit die langlaufenden statements unter die Lupe nehmen. Danach vernünftig Indizieren oder die Abfragen vernünftig anpassen. Möglichst Joins mit grossen Ergebnissmengen z.B. vermeiden.

[fulltilt]

Hm - problematisch ist nur, das ich an den PHP Scripts der Kunden nicht arbeiten will und darf :-)
Daher müsste ich eine Lösung über die Mysql / PHP Confs finden um das systemübergreifend einzustellen.

Gruss
Ralph

Danke - könnte die Erhöhung der join_buffer_size noch etwas bringen?

Jaein,

eine Join kann je nach komplexität einen Ergebnissmenge von n*m erzeugen
Also 1000 Rows mal 1000 Rows.

Mit jeder Tabelle dazu gehört, kann sich das noch mehr vergrössern. Hier hilft nur eine brauchbare Indizierung z.B.

Gruss Matthias

[fulltilt]

Habe bereits einige Webs testweise gesperrt - allerdings denke ich das hier wirklich zu viele Tabellen die Ursache sind und die Confs nicht ganz optimal. Dazu kommen dann noch die php5-cgi Prozesse - habe noch eine alte ispCP RC3 auf diesem System im Einsatz ... die werde ich morgen auch noch upgraden.

Du darfst doch aber wenigstens dem einen Kunden die Präsenz abdrehen, wenn er dafür verantwortlich ist, dass alles lahmt und hängt oder?
Ermittle erstmal die Ursache und dann reden wir über die Mögliche Lösung. Und wenn Dein Kunde völligen Misst baut,
musst Du Ihm ggf. auch die Schranken weisen.
Gruss Matthias

[fulltilt]

Danke - werde ich machen :-)

allerdings denke ich

Worin liegt das Problem show full processlist auszuführen und mal einen Blick auf die mLaufzeiten zu werfen?
2. das slow query log zu prüfen und
3. zu guter letzt noch die Querys raus loggen lassen, die keinen Indexe verwenden?

Bei einem Kunden wo wirklich erfahrene Entwickler arbeiten hatte man vor meinem hinzu kommen gut 6-7 Monate verbracht Performance Problem zu beheben.
Ohne Erfolg.
Danach http://www.rootforum.org/forum/viewtopi ... 04&t=49166
Habe ich das Probem genauer analysiert und konnte die Ursache finden.
Die Behebung des Problems war leider nur teilweise und mit einem Upgrade der DB möglich.
Was ich damit sagen will, Performance Optimierungen funktionieren ganz selten mit einem schnell klick und ganz wenig Aufwand mit einem wunderprächtigen Ergebnis.

[fulltilt]

Die Sache spitzt sich zu ...
Ich habe gestern ein Problem Web gesperrt und 5 weitere auf ein anderes System verlegt, danach ging die Load von 18 bis 2:50 Uhr wieder in den normalen Bereich - unter 2.
Um 2:50 Uhr wurden dann die awstats crons gestartet und die Load ging für 3 Stunden auf 133 % - dieser Cron hat in der letzten Woche mit ca. 60 Domains mehr, höchstens eine Load von 4 verursacht.
Es liegt sicher nicht an der awstats cron - ich habe irgendwie den Eindruck, das dieses System nicht mehr mit Load umgehen kann ...
Was kann das noch sein?

#EDIT#
Hier noch ein paar Ausgaben:
lsof | grep apache2 | wc -l = 2874
lsof | grep mysql | wc -l = 3720
cat /proc/sys/fs/file-nr = 10656 0 199880

der hier scheint mir doch etwas sehr hoch - oder?
lsof | grep php | wc -l = 18654

/dev/sda:
IO_support = 0 (default 16-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 312581808, start = 0

/dev/sda1:

Model=MAXTOR STM3160811AS , FwRev=3.AAE , SerialNo= 6PT4987E
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

* signifies the current active mode

[Joe User]

Hier noch ein paar Ausgaben:
lsof | grep apache2 | wc -l = 2874
lsof | grep mysql | wc -l = 3720
cat /proc/sys/fs/file-nr = 10656 0 199880

der hier scheint mir doch etwas sehr hoch - oder?
lsof | grep php | wc -l = 18654

Ja, alle drei Werte sind IMHO zu hoch. Wie hast Du Apaches Prozesse und FastCGI konfiguriert?

[daemotron]

Man müsste jetzt mal etwas mehr über die Gesamtkonfiguration Deines Systems wissen. MySQL allein kann keine allzu hohe Load verursachen, da der Load-Wert ja der Durchschnitt der im betrachteten Zeitraum aktiven Prozesse ist (und MySQL ein Single Process/Multi-Thread Daemon ist). Die Frage ist also, welche Prozesse da aktiv sind. Auch ein einzelner Cron-Job (AWStats) kann Deine Load eigentlich nicht in solche Mondbereiche jagen. Typische Load-Treiber sind eigentlich Apache oder FastCGI-Prozesse, auch der Mailserver oder ein Spamfilter können dahinter stecken.

Dass php so viele offene File Handles hat, könnte eventuell darauf hindeuten, dass Dein System I/O-Probleme hat. Wie hoch ist denn der wa-Wert (I/O-Wait), wenn die Load deutlich >1 ist? Mögliche Ursachen: es wird zu viel ein-/ausgelagert, eine Platte läuft ohne oder mit falsch konfiguriertem DMA, es sind zu wenige/kleine zusammenhängende Speicherbereiche frei, die Platte hat einen Hardware-Defekt, usw.

[fulltilt]

Hier noch ein paar Ausgaben:
lsof | grep apache2 | wc -l = 2874
lsof | grep mysql | wc -l = 3720
cat /proc/sys/fs/file-nr = 10656 0 199880

der hier scheint mir doch etwas sehr hoch - oder?
lsof | grep php | wc -l = 18654

Ja, alle drei Werte sind IMHO zu hoch. Wie hast Du Apaches Prozesse und FastCGI konfiguriert?

Danke - hier sind die confs:
Timeout 30
KeepAlive On
MaxKeepAliveRequests 10
KeepAliveTimeout 2
<IfModule mpm_worker_module>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 500
</IfModule>

mod fcgi.conf:
FastCgiConfig -minProcesses 1
-maxProcesses 400
-maxClassProcesses 5
-multiThreshold 80
-killInterval 60
-startDelay 5

die php5-fcgi-starter.tpl
export PHPRC
PHP_FCGI_CHILDREN=2
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=500
export PHP_FCGI_MAX_REQUESTS

[fulltilt]

Mögliche Ursachen: es wird zu viel ein-/ausgelagert, eine Platte läuft ohne oder mit falsch konfiguriertem DMA, es sind zu wenige/kleine zusammenhängende Speicherbereiche frei, die Platte hat einen Hardware-Defekt, usw.

Hatte die awstats cron und Mailscanner gestern den ganzen tag deaktiviert - ich habe auch schon auf ein Hardwareproblem getippt - hier noch mehr output:

Code: Select all

iostat:
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20,00    0,68    7,73    3,82    0,00   67,76

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda              24,27       284,49       215,84  109528522   83096760
sdb               2,21        58,12        26,38   22375794   10157608

mpstat:
14:52:16     CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
14:52:16     all   20,00    0,68    7,39    3,82    0,09    0,25    0,00   67,76    138,29


cat /proc/meminfo
MemTotal:      2010660 kB
MemFree:         58000 kB
Buffers:        124636 kB
Cached:         583264 kB
SwapCached:     232584 kB
Active:        1580184 kB
Inactive:       268340 kB
HighTotal:     1113792 kB
HighFree:         2428 kB
LowTotal:       896868 kB
LowFree:         55572 kB
SwapTotal:     3943948 kB
SwapFree:      3248776 kB
Dirty:             404 kB
Writeback:           0 kB
AnonPages:     1102764 kB
Mapped:         323104 kB
Slab:            78800 kB
SReclaimable:    54536 kB
SUnreclaim:      24264 kB
PageTables:      13364 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   4949276 kB
Committed_AS:  4667492 kB
VmallocTotal:   114680 kB
VmallocUsed:      2300 kB
VmallocChunk:   112292 kB

ps -ef |grep mysqld
root      6538     1  0 Oct10 ?        00:00:00 /bin/sh /usr/bin/mysqld_safe
mysql     6577  6538  3 Oct10 ?        01:42:26 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/run/mysqld/mysqld.sock
root      6579  6538  0 Oct10 ?        00:00:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
root     11997 11796  0 14:45 pts/0    00:00:00 grep mysqld

[fulltilt]

Poste doch einfach mal, was Dir Top so sagt.

also momentan ist die Load so zwischen 0,5 und 3,5 - ist nicht sehr viel los im Moment:
Was mir aber noch aufegfallen ist, das wenn es losgeht zuviele laufende Tasks (10 - 30) einmal aus dem nichts kommen und die Load bis zum Anschlag hochjagen.

top:
top - 14:57:48 up 4 days, 10:56, 1 user, load average: 0.63, 0.71, 0.69
Tasks: 303 total, 3 running, 300 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.0%us, 1.3%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2010660k total, 1951604k used, 59056k free, 80728k buffers
Swap: 3943948k total, 694780k used, 3249168k free, 629248k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11466 www-data 18 0 250m 20m 2312 S 2.0 1.0 0:29.44 apache2
12826 root 15 0 2360 1264 856 R 1.6 0.1 0:00.17 top
4087 vu2439 18 0 53492 9536 2608 S 0.3 0.5 0:00.36 php5-cgi
1 root 15 0 1948 552 528 S 0.0 0.0 0:04.42 init
2 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 34 19 0 0 0 S 0.0 0.0 0:01.97 ksoftirqd/0
5 root 10 -5 0 0 0 S 0.0 0.0 0:00.10 events/0
6 root 11 -5 0 0 0 S 0.0 0.0 0:00.01 khelper
41 root 10 -5 0 0 0 S 0.0 0.0 1:12.50 kblockd/0
42 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
43 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpi_notify
153 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 ata/0
154 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 ata_aux
155 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
179 root 17 -5 0 0 0 S 0.0 0.0 3:14.95 kswapd0
180 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0

[fulltilt]

Eine DOS Attacke also. Scheint derzeit öfters vor zu kommen.

Ich könnte mal die HTTP Zugriffe mit iptables oder dos-deflate einschränken ...
Aber seltsam ist wirklich das auch wenn der Apache nicht läuft und ich packe z.B. eine grössere Datei, dann gehts auch ungewöhnlich rauf. Vieleicht doch eher Richtung Hardware > Disk ...

Code: Select all

DF
/dev/sda1            149952572  35643072 106692284  26% /
tmpfs                  1005328         0   1005328   0% /lib/init/rw
tmpfs                  1005328         0   1005328   0% /dev/shm
/dev/sdb1            153834852  35120016 110900420  25% /mnt/backup


cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 55
model name      : AMD Athlon(tm) 64 Processor 3700+
stepping        : 2
cpu MHz         : 2197.422
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm ts fid vid ttp
bogomips        : 4403.96
clflush size    : 64

[fulltilt]

Was heisst, wenn Du eine Datei packst, geht es ungewöhnlich hoch rauf?

Die Load geht dann auf 5-6 ...
Hier aber nochmal ein top wo es wieder etwas anzieht:

Code: Select all

top - 15:20:00 up 4 days, 11:18,  2 users,  load average: 1.13, 0.99, 0.83
Tasks: 317 total,   2 running, 315 sleeping,   0 stopped,   0 zombie
Cpu(s): 29.6%us, 18.2%sy,  2.0%ni, 48.5%id,  1.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2010660k total,  1941844k used,    68816k free,   126588k buffers
Swap:  3943948k total,   692624k used,  3251324k free,   551132k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
26302 vu2300    18   0 55808  15m 8404 S 27.5  0.8   3:15.54 php5-cgi
 2909 vu2152    22   0 56184  12m 8356 S  7.9  0.6   0:13.26 php5-cgi
12125 www-data  18   0  251m  20m 2316 S  5.2  1.1   0:40.58 apache2
 6577 mysql     17   0  455m 212m 4300 S  2.3 10.8 102:48.01 mysqld
14081 www-data  19   0  249m  19m 2296 S  1.6  1.0   0:08.90 apache2
15215 root      15   0  2360 1272  856 R  1.6  0.1   0:00.91 top
15012 zabbix    20   5  3208  796  684 S  0.3  0.0   0:24.07 zabbix_agentd
    1 root      15   0  1948  552  528 S  0.0  0.0   0:04.43 init
    2 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
    4 root      34  19     0    0    0 S  0.0  0.0   0:01.97 ksoftirqd/0
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.10 events/0
    6 root      11  -5     0    0    0 S  0.0  0.0   0:00.01 khelper
   41 root      10  -5     0    0    0 S  0.0  0.0   1:12.63 kblockd/0
   42 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
   43 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpi_notify
  153 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 ata/0

[fulltilt]

Es ist auch momentan nicht wirklich viel los auf diesem Rechner, es kommt aber trotzdem bei diesen wenigen Verbindungen immer wieder zu einer Load von 3 - 4 momantan. Letztere mit den 38 Verbindungen ist mein Zabbix Server

Code: Select all

netstat :
      1 66.249.xx.xx
      1 74.6.xx.xx
      1 85.94.255.224
      1 88.80.xx.xx
      2 74.125.xx.xx
      2 83.99.xx.xx
      3 195.218.xx.xx
      5 83.99.xx.xx
      9 91.34.xx.xx
     23 0.0.0.0
     38 83.xxx.xx.xx
    139 127.0.0.1

[Joe User]

Sollte etwas helfen, aber das Problem nicht wirklich lösen, siehe die anderen Antworten:

httpd.conf:

Code: Select all

Timeout 3
KeepAlive Off
MaxKeepAliveRequests 10
KeepAliveTimeout 2
<IfModule mpm_worker_module>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 500
</IfModule>

mod_fcgi.conf:

Code: Select all

FastCgiConfig -minProcesses 1 
-maxProcesses 20 
-maxClassProcesses 5 
-multiThreshold 80 
-killInterval 60 
-startDelay 5

php5-fcgi-starter.tpl:

Code: Select all

export PHPRC
PHP_FCGI_CHILDREN=8
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=500
export PHP_FCGI_MAX_REQUESTS

[fulltilt]

Danke Joe User - werde es mal so testen.
Wenn die fcgi maxProcesses soweit runter gesetzt werden, würde das denn nicht noch mehr Load erzeugen wenn viele Zugriffe erfolgen?

Sollte etwas helfen, aber das Problem nicht wirklich lösen, siehe die anderen Antworten:

httpd.conf:

Code: Select all

Timeout 3
KeepAlive Off
MaxKeepAliveRequests 10
KeepAliveTimeout 2
<IfModule mpm_worker_module>
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 500
</IfModule>

mod_fcgi.conf:

Code: Select all

FastCgiConfig -minProcesses 1 
-maxProcesses 20 
-maxClassProcesses 5 
-multiThreshold 80 
-killInterval 60 
-startDelay 5

php5-fcgi-starter.tpl:

Code: Select all

export PHPRC
PHP_FCGI_CHILDREN=8
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=500
export PHP_FCGI_MAX_REQUESTS

[fulltilt]

Jetzt gehts wieder los:
Dabei ist 10 running tasks noch harmlos - ging schon auf 30-40.

Code: Select all

top - 18:01:12 up 4 days, 13:59,  1 user,  load average: 4.76, 3.30, 1.79
Tasks: 335 total,  10 running, 325 sleeping,   0 stopped,   0 zombie
Cpu(s): 51.6%us,  8.2%sy,  1.6%ni, 32.7%id,  5.6%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   2010660k total,  1925032k used,    85628k free,    58008k buffers
Swap:  3943948k total,   686788k used,  3257160k free,   553016k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13832 vu2131    17   0 53592 8176 4612 R 39.0  0.4   0:33.16 php5-cgi
27942 www-data  18   0  250m  19m 2300 S  8.6  1.0   0:13.99 apache2
27580 www-data  18   0  250m  19m 2304 S  5.1  1.0   0:26.74 apache2
20443 vu2131    18   0 53592 8088 4680 R  2.9  0.4   0:26.83 php5-cgi
28494 root      16   0  2360 1276  856 R  2.6  0.1   0:00.22 top
28495 vu2430    15   0  8740 3508 2068 S  1.0  0.2   0:00.15 proftpd
    1 root      15   0  1948  552  528 S  0.0  0.0   0:04.45 init
    2 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 migration/0
    4 root      34  19     0    0    0 S  0.0  0.0   0:01.98 ksoftirqd/0
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.10 events/0
    6 root      11  -5     0    0    0 S  0.0  0.0   0:00.01 khelper
   41 root      10  -5     0    0    0 S  0.0  0.0   1:12.80 kblockd/0
   42 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
   43 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpi_notify
  153 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 ata/0
  154 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 ata_aux

Mir ist noch aufgefallen in den Logs, das wenn die Load höher geht meistens Seiten mit Bildern (fotoalben) aufgerufen werden. Könnte vieleicht noch etwas mit php / GD zu tun haben ...

[fulltilt]

Durachsus denkbar denn die Mysql DB reiht sich nicht in den obern Reihen ein. Werden etwa Bilder z.B. thumbnails etc. on the fly beim Zugriff erzeugt?
Gruss Matthias

Ja - davon gibt es einige Webs die z.B. auch die Vorschaubilder so generieren ...
Habe auf diesem System nur GD2 im Einsatz was PHP bestrifft, ansonsten noch mod_deflate im Apachen.

[fulltilt]

Dann brauchst Du Dich nicht wundern, wenn sich das als Angriffsfläche nutzt.
Die Bilder sollten von der Platte ausgeliefert werden und nicht zur Auslieferung bearbeitet werden.

Na ja - ich bin mir noch nicht so sicher ob die Load wirklich auf Angriffe zurückzuführen ist.
Habe auch eben nochmal die apache und mod_security2 Logs geprüft - nichts auffälliges.

Ich habe hier noch eine alte ispCP RC3 drauf laufen - ich werde die heute Nacht auf jeden Fall upgraden.
Da gibt es ein paar Änderungen vom Logsystem und libapache2-mod-fcgid ...
Meine PHP Templates sind bereits ganz gut abgesichert - ich werde aber nachher nochmal die php.ini checken.
Werde Euch morgen berichten wie es aussieht :-)

[fulltilt]

Bin gerade noch alles auf einer VM am testen - dabei migriere ich testweise die ganzen User ...
Noch mal zu Mysql - hier ist mir folgendes noch aufgefallen:

du -s /var/lib/mysql/*
Produktivsystem
330056 /var/lib/mysql/ibdata1

testserver (komplette Datenbank importiert):
34856 /var/lib/mysql/ibdata1

ziehe jetzt alle möglichen Ursachen in Erwägung :-)
Könnte es damit auch zu tun haben?

[fulltilt]

Also sehr viel geändert hat sich leider nicht durch das Update.
Habe hier noch einen Beitrag gefunden (die Option PHP_FCGI_CHILDREN einfach rauslassen) aus dem starter - ist das noch aktuell?

Ich bin mir jetzt sehr sicher, das die Last von Mysql erzeugt wird ...
Gibt es da nicht noch eine Möglichkeit die Werte zu verbessern?
so sieht sie momentan aus - habe die Join Buffer Size und die TMP/HEAP erhöht, leider ohne spürbaren Erfolg - tuning-primer meint, so wäre es okay ...

Code: Select all

skip-external-locking
skip_name_resolve
skip_locking
key_buffer      = 32M
join_buffer_size        = 8M
sort_buffer             = 2M
read_buffer_size        = 2M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size = 64M
max_allowed_packet   = 32M
thread_stack      = 128K
thread_cache_size   = 16
max_connections         = 100
table_cache            = 13000
thread_concurrency     = 16
max_heap_table_size       = 400M
tmp_table_size            = 400M
open_files_limit          = 32000
query_cache_type                = 1
query_cache_size                = 128M
query_cache_limit               = 16M
max_connect_errors        = 10
log_warnings              = 2
long_query_time           = 3
log_slow_queries          = /var/log/mysql/mysql-slow.log
log_queries_not_using_indexes
skip-bdb
[mysqldump]
quick
quote-names
max_allowed_packet   = 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer_size       = 128M
[myisamchk]
key_buffer_size       = 128M

myisam_repair_threads           = 1
myisam_recover = FORCE,BACKUP
[mysqlhotcopy]
interactive-timeout

[fulltilt]

Zu 1. was Du uns bislang geliefert hast, deutet nicht darauf hin.
2. Eventuell ja Query Cache z.B. vergrössern.
Suche die Ursache und beseitige diese.

Die kommen hauptsächlich von 3 grossen Shopsystem - grosse Tabellen und Generierung der Thumbs über Querys.
Die User habe ich bereits benachrichtigt um Indexe anzulegen, werde diese Webs erstmal auf ein anders System umziehen.
Hier denke ich das die Hardware nicht ausreichend Resourcen hat, werde aber auch noch mit einem grösseren Query Cache testen.

[fulltilt]

-> Und hast Du auch eine Idee, wie die Datensätze zusammen wirken, was indiziert werden sollte?
`explain` ist hierbei ein sehr nützliches Mysql tool.

Danke für den Tip.
Habs schon mal bei einer Online Auktion hinbekommen, ich lege diese aber erst mal auf ein System mit mehr Recourcen.
Hier müssen die Kunden sich darum kümmern oder jemanden beauftragen - die Datenbanken werden ja nicht kleiner ...

Noch was anderes:
Habe ja 2 SATA Platten im Problem Rechner - hälst Du es für sinnvoll bei sata noch zu tunen z.b. mit sdparm?
/dev/sda:
Timing cached reads: 240 MB in 2.00 seconds = 119.78 MB/sec
Timing buffered disk reads: 142 MB in 3.04 seconds = 46.71 MB/sec

/dev/sdb:
Timing cached reads: 296 MB in 2.01 seconds = 147.31 MB/sec
Timing buffered disk reads: 142 MB in 3.02 seconds = 47.06 MB/sec

SDA >
Model=MAXTOR STM3160811AS , FwRev=3.AAE , SerialNo= 6PT4987E
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled

[Joe User]

Also sehr viel geändert hat sich leider nicht durch das Update.

Sofern Du Debian einsetzt: http://www.rootforum.org/forum/viewtopi ... 32#p240232

Habe hier noch einen Beitrag gefunden (die Option PHP_FCGI_CHILDREN einfach rauslassen) aus dem starter - ist das noch aktuell?

Nein.

Ich bin mir jetzt sehr sicher, das die Last von Mysql erzeugt wird ...

Wieso?

Gibt es da nicht noch eine Möglichkeit die Werte zu verbessern?
so sieht sie momentan aus - habe die Join Buffer Size und die TMP/HEAP erhöht, leider ohne spürbaren Erfolg - tuning-primer meint, so wäre es okay ...

tmp/heap zu erhöhen ist bei den unoptimierten Applikationen nicht sinnvoll, da die meisten tmp-tables eh on-disk sein werden.

Code: Select all

key_buffer      = 32M
thread_stack      = 128K
table_cache            = 13000

key_buffer ist zu klein, der table_cache ist zu hoch und am thread_stack spielt man nicht ohne zu wissen, was man macht...

[daemotron]

Hier denke ich das die Hardware nicht ausreichend Resourcen hat, werde aber auch noch mit einem grösseren Query Cache testen.

Was mir extrem merkwürdig vorkommt, ist die Tatsache, dass Dein System relativ viel swappt (~700MB, obwohl Cache + Buffer + Free etwa dieselbe Größenordnung ergeben). Hast Du irgendwo mal an der Swappiness gedreht? Ich hätte jetzt einfach Bedenken, dass eine Vergrößerung diverser MySQL-Caches ebenfalls dazu führt, dass der dafür alloziierte Speicher einfach ausgelagert wird, womit Du nichts gewonnen hast (außer noch mehr I/O-Wait). Ansonsten deutet aber alles darauf hin, dass Deinem System einfach ein bisschen RAM fehlt, um a) nicht dauernd zu swappen (was auch den mysqld ausbremst, da der Plattenzugriff immer wieder blockiert wird => I/O-Wait) und b) Deinen mysqld mit entsprechenden Caches auszustatten.

Ggf. kannst Du ein bisschen was freischaufeln, wenn Du die doch recht fetten Apache-Prozesse etwas entschlackst (überflüssige LoadModule-Anweisungen rauswerfen) oder einen schlankeren httpd einsetzt. Dasselbe gilt für PHP => nicht benötigte Module rauswerfen, und ansonsten mal Deine komplette Prozessliste durchgehen (am besten nach VIRT sortieren) und die echten Speicherfresser mal identifizieren.