Mich trifft gerade der Schlag

Kato

Registered User
Vor ein paar Tage sah das top noch viel besser aus. Eben trifft micht der Schlag:
Code:
top - 17:06:50 up 92 days, 15:04,  1 user,  load average: 42.79, 31.25, 23.77
Tasks: 206 total,  59 running, 146 sleeping,   0 stopped,   1 zombie
Cpu(s): 93.3%us,  5.8%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.2%hi,  0.7%si,  0.0%st
Mem:   4043580k total,  2973576k used,  1070004k free,   247432k buffers
Swap:  1999928k total,    10512k used,  1989416k free,   945320k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
24151 mysql     20   0  513m 164m 6112 S   26  4.2   5:18.18 mysqld
25911 www-data  20   0  456m  31m  16m R    3  0.8   0:00.98 apache2
25947 www-data  20   0  456m  31m  16m R    3  0.8   0:00.72 apache2
25975 www-data  20   0  456m  31m  17m R    3  0.8   0:00.72 apache2
25976 www-data  20   0  456m  31m  17m R    3  0.8   0:00.90 apache2
25992 www-data  20   0  456m  30m  16m R    3  0.8   0:00.76 apache2
26038 www-data  20   0  456m  31m  16m R    3  0.8   0:00.70 apache2
26046 www-data  20   0  456m  30m  16m R    3  0.8   0:00.76 apache2
26047 www-data  20   0  456m  31m  16m R    3  0.8   0:00.76 apache2
26060 www-data  20   0  456m  30m  16m R    3  0.8   0:00.74 apache2
26295 www-data  20   0  456m  30m  16m R    3  0.8   0:00.22 apache2
26297 www-data  20   0  456m  30m  16m R    3  0.8   0:00.22 apache2
26300 www-data  20   0  455m  30m  16m R    3  0.8   0:00.22 apache2
24734 www-data  20   0  461m  43m  24m R    3  1.1   0:05.82 apache2
25026 www-data  20   0  456m  31m  17m R    3  0.8   0:02.56 apache2
25037 www-data  20   0  456m  31m  17m R    3  0.8   0:03.04 apache2
25828 www-data  20   0  456m  31m  16m R    3  0.8   0:00.98 apache2
25830 www-data  20   0  456m  31m  17m R    3  0.8   0:00.68 apache2
25831 www-data  20   0  456m  31m  16m R    3  0.8   0:01.08 apache2
25921 www-data  20   0  456m  30m  16m R    3  0.8   0:00.84 apache2
25928 www-data  20   0  456m  30m  16m R    3  0.8   0:00.74 apache2
25978 www-data  20   0  456m  31m  17m R    3  0.8   0:00.80 apache2
25982 www-data  20   0  456m  30m  17m R    3  0.8   0:00.72 apache2
25993 www-data  20   0  456m  30m  16m R    3  0.8   0:00.72 apache2
25996 www-data  20   0  456m  31m  16m R    3  0.8   0:00.78 apache2
26000 www-data  20   0  456m  32m  18m R    3  0.8   0:00.62 apache2
26036 www-data  20   0  456m  31m  16m R    3  0.8   0:00.58 apache2
26294 www-data  20   0  455m  30m  16m R    3  0.8   0:00.24 apache2
26298 www-data  20   0  455m  30m  16m R    3  0.8   0:00.22 apache2
26299 www-data  20   0  455m  30m  16m R    3  0.8   0:00.26 apache2
26302 www-data  20   0  456m  30m  16m R    3  0.8   0:00.24 apache2
26315 www-data  20   0  452m  20m  10m R    3  0.5   0:00.08 apache2
26323 www-data  20   0  452m  20m  10m R    3  0.5   0:00.10 apache2
24540 www-data  20   0  456m  33m  19m R    2  0.8   0:06.24 apache2
24878 www-data  20   0  456m  32m  18m R    2  0.8   0:03.48 apache2
25041 www-data  20   0  456m  31m  17m R    2  0.8   0:03.26 apache2
25803 www-data  20   0  455m  31m  17m S    2  0.8   0:01.66 apache2

Der Apache reagiert aber immer noch flüssig. Die Auslieferung der Seiten funktioniert.

Ich dachte eigentlich, dass ich ihn gerade optimiert hatte. Hier meine conf:
Code:
Timeout 60
KeepAlive Off
MaxKeepAliveRequests 0
KeepAliveTimeout 5
StartServers         5
MinSpareServers      5
MaxSpareServers      10
ServerLimit          200    
MaxClients           200
MaxRequestsPerChild  0

Die MySQL-Einstellungen orientierten sich am tuning-primer:
Code:
             - By: Matthew Montgomery -

MySQL Version 5.0.51a-24+lenny2 x86_64

Uptime = 0 days 0 hrs 12 min 20 sec
Avg. qps = 302
Total Questions = 223812
Threads Connected = 5

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 5 sec.
You have 356 out of 223872 that take longer than 5 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 16
Current threads_cached = 7
Current threads_per_sec = 0
Historic threads_per_sec = 1
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 768
Current threads_connected = 9
Historic max_used_connections = 232
The number of used connections is 30% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 869 M
Configured Max Per-thread Buffers : 2.62 G
Configured Max Global Buffers : 58 M
Configured Max Memory Limit : 2.67 G
Physical Memory : 3.85 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 5 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 1053
Key buffer free ratio = 79 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 1 M
Current query_cache_limit = 32 M
Current Query cache Memory fill ratio = 4.69 %
Current query_cache_min_res_unit = 2 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 1.00 M
You have had 5 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 3840 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 768 tables
You have a total of 271 tables
You have 561 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 64 M
Current tmp_table_size = 64 M
Of 8345 temp tables, 25% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 536 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 597
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.
Jetzt hatte ich die DB dummerweise gerade neugestartet bevor ich das Skript laufen habe lassen.....:mad:
Sagt also nicht mehr soviel aus. Ich hatte mich aber bisher an den Ausgaben des Skrips orientiert, sodass es da in der Vergangenheit keine extremen Misseinstellungen gab.

Auf dem Server läuft ein Joomla mit bis zu 400 Usern gleichzeitig online.

Hat jemand Tips oder Erfahrungen woran ich noch schrauben könnte?
 
Was sagt denn netstat? Schon das access.log gecheckt? Nur um auszuschliessen dass es ein Angriff oder aggressiver Scan ist.
Zumindest "Avg. qps = 302" ist meiner Meinung nach ein Hinweis darauf....auf einem meiner Server auf dem 50 Sites laufen (darunter zumindest 4 sehr gut frequentierte) sind es gerade mal Avg. qps = 6.
 
Last edited by a moderator:
:eek:Oh Gott das wird immer schlimmer:

Code:
top - 21:32:39 up 92 days, 19:29,  1 user,  load average: 153.47, 136.79, 95.89
Tasks: 272 total, 114 running, 158 sleeping,   0 stopped,   0 zombie
Cpu(s): 92.2%us,  6.2%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.3%hi,  1.3%si,  0.0%st
Mem:   4043580k total,  4008916k used,    34664k free,   259032k buffers
Swap:  1999928k total,    10512k used,  1989416k free,   923036k cached

Nach was soll ich denn im access.log Ausschau halten um einen Angriff identifizieren zu können? Und was kann ich selbst tun?

Ich poste auch nochmal den output vom primer:

Code:
MySQL Version 5.0.51a-24+lenny2 x86_64

Uptime = 0 days 4 hrs 34 min 23 sec
Avg. qps = 286
Total Questions = 4717451
Threads Connected = 338

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 5 sec.
You have 5510 out of 4717506 that take longer than 5 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html

WORKER THREADS
Current thread_cache_size = 16
Current threads_cached = 6
Current threads_per_sec = 0
Historic threads_per_sec = 1
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 768
Current threads_connected = 337
Historic max_used_connections = 367
The number of used connections is 47% of the configured maximum.
Your max_connections variable seems to be fine.

MEMORY USAGE
Max Memory Ever Allocated : 1.30 G
Configured Max Per-thread Buffers : 2.62 G
Configured Max Global Buffers : 58 M
Configured Max Memory Limit : 2.67 G
Physical Memory : 3.85 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 5 M
Current key_buffer_size = 16 M
Key cache miss rate is 1 : 1165
Key buffer free ratio = 75 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 4 M
Current query_cache_limit = 32 M
Current Query cache Memory fill ratio = 13.15 %
Current query_cache_min_res_unit = 2 K
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 1.00 M
You have had 13 queries where a join could not use an index properly
You have had 1 joins without keys that check for key usage after each row
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 3840 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 768 tables
You have a total of 277 tables
You have 768 open tables.
Current table_cache hit rate is 76%, while 100% of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 64 M
Current tmp_table_size = 64 M
Of 147742 temp tables, 26% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 310 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 446
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'
If you have a high concurrency of inserts on Dynamic row-length tables
consider setting 'concurrent_insert=2'.

Der Apache liefert zwar noch aus (Ein Indianer kennt keinen Schmerz :cool:) aber schon nicht mehr ganz so flüssig.
 
Koennte es -rein zufaellig- sein dass nicht MySQL sondern die Anzahl an gleichzeitigen HTTP-Verbindungen Schuld an der Misere ist? Ich glaube naemlich entsprechende Andeutungen aus dem 'Top'-Auszug auslesen zu vermoegen...

Wieviele gleichzeitige Verbindungen sind auf dem Server offen
Wieviele gleichzeitige Anfragen bearbeitet Apache
Wieviele gleichzeitige Apache Worker sind aktiv
VOn wo kommen alle Anfragen?

Einen Angriff erkennst du daran dass die IP's sich regelmaessig wiederholen oder dauernd entweder die gleiche Datei oder nicht existente Dateien abgefragt werden.

Edit: koennte es nicht evtl auch an MaxRequestsPerChild 0 liegen? ;)
Ein zumindest sehr gefaehrlicher Wert!
 
Koennte es -rein zufaellig- sein dass nicht MySQL sondern die Anzahl an gleichzeitigen HTTP-Verbindungen Schuld an der Misere ist? Ich glaube naemlich entsprechende Andeutungen aus dem 'Top'-Auszug auslesen zu vermoegen...

Wieviele gleichzeitige Verbindungen sind auf dem Server offen
Wieviele gleichzeitige Anfragen bearbeitet Apache
Wieviele gleichzeitige Apache Worker sind aktiv
VOn wo kommen alle Anfragen?

Einen Angriff erkennst du daran dass die IP's sich regelmaessig wiederholen oder dauernd entweder die gleiche Datei oder nicht existente Dateien abgefragt werden.

Edit: koennte es nicht evtl auch an MaxRequestsPerChild 0 liegen? ;)
Ein zumindest sehr gefaehrlicher Wert!

Ich versuche seit ca. 1 Woche durch Apache Tuning die Leistung zu verbessern. Meine conf sah bis vor ein paar Tagen noch ganz anders aus Der Apache lief und er lief nicht mal schlecht (also auf gar keinen Fall kame top-Werte wie oben zustande).
Beim Tuning habe ich z.B. das gefunden, worauf auch meine maxClient und auch der MaxRequestsPerChild Wert beruhten: http://www.huschi.net/archiv/hochleistungs-apache-performance-tuning.html

Ich werde aber mal verschiedene Werte für diese Variable ausprobieren. An den MySQL Einstellungen hatte ich nichts geändert.

Zu deinen anderen Fragen kann ich im Moment noch nichts sagen, da muss ich erst die Werte herausfinden. In den logs habe ich nun nichts Auffälliges gefunden. Weder immer wieder die gleiche IP, noch immer wieder der Aufruf von gleichen Dateien oder Fehlermeldungen (404 etc.).

Aber ich suche weiter.
 
Gib mal:

netstat -anp

oder

netstat -anp | grep SYN

ein. Du solltest schon auf die Postings derer hören, die dir hier helfen sollen.
 
Du solltest schon auf die Postings derer hören, die dir hier helfen sollen.

Versuch ich doch. Ich weiß auch nicht, wie du zum gegenteiligen Eindruck kommst.

Gib mal:

netstat -anp

oder

netstat -anp | grep SYN

ein. Du solltest schon auf die Postings derer hören, die dir hier helfen sollen.

netstat -anp | grep SYN ergibt

Code:
netstat -anp | grep SYN
tcp        0      0 XXX.XXX.XXX.XXX:80        81.154.139.89:2219      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        76.180.27.133:1357      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        78.150.70.86:10754      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        86.41.185.138:63070     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        78.150.70.86:10753      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        213.196.82.141:61071    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        81.104.26.205:50988     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        84.168.56.67:61375      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        200.104.201.202:61301   SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        144.85.154.29:17955     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        76.180.27.133:1361      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        84.158.220.21:53910     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        144.85.154.29:17954     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        62.158.18.238:59288     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        144.85.154.29:17953     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        84.168.56.67:61373      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        72.20.18.199:53556      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        98.211.24.43:50617      SYN_RECV    -

Das ist ungekürzt. Da hatte ich eben aber auch ein top, das so aussah (mit unveränderter conf.)

Code:
top - 00:45:09 up 92 days, 22:42,  1 user,  load average: 3.38, 9.98, 19.53
Tasks: 107 total,   8 running,  99 sleeping,   0 stopped,   0 zombie
Cpu(s): 60.2%us,  7.8%sy,  0.0%ni, 31.3%id,  0.0%wa,  0.2%hi,  0.5%si,  0.0%st
Mem:   4043580k total,  1972468k used,  2071112k free,   265044k buffers
Swap:  1999928k total,    10512k used,  1989416k free,   929152k cached

Die load average schwankt total ohne dass ich groß Dinge verändere.

Ein aktuelles netstat ergibt
Code:
netstat -anp | grep SYN
tcp        0      0 XXX.XXX.XXX.XXX:80        67.149.50.91:61146      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        82.113.121.248:15471    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        82.113.121.248:47927    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        69.205.227.255:49313    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        69.205.227.255:49314    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        82.113.121.248:41959    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        82.113.121.248:40299    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        72.84.159.73:55495      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        69.205.227.255:49317    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        86.154.35.128:64315     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        82.113.121.248:1764     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        213.67.210.226:50157    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        82.113.121.248:21761    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        86.154.35.128:64314     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        70.71.239.206:40968     SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        72.84.159.73:55525      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        72.84.159.73:55492      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        82.113.121.248:21186    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        72.84.159.73:55491      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        72.84.159.73:55526      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        72.84.159.73:55493      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        67.149.50.91:61147      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        69.205.227.255:49315    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        98.211.24.43:50757      SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        71.201.243.103:62420    SYN_RECV    -
tcp        0      0 XXX.XXX.XXX.XXX:80        69.205.227.255:49316    SYN_RECV    -

bei einem top, das so aussieht:
Code:
top - 00:57:58 up 92 days, 22:55,  1 user,  load average: 67.14, 56.12, 35.79
Tasks: 209 total,  27 running, 181 sleeping,   0 stopped,   1 zombie
Cpu(s): 15.1%us,  2.2%sy,  0.0%ni, 81.3%id,  1.0%wa,  0.1%hi,  0.3%si,  0.0%st
Mem:   4043580k total,  3239816k used,   803764k free,   266012k buffers
Swap:  1999928k total,    10512k used,  1989416k free,   915440k cached

Jetzt habe ich auch einmal ein netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n gemacht, das die Anzahl der Verbindungen pro IP ausgibt. Da sehe ich dann schon seltsame Werte. Die höchsten sehen so aus:
Code:
101 81.99.70.70
125 94.192.220.52
126 81.156.232.220
142 75.73.12.224
152 144.85.154.29
Mir erscheinen 100 Verbindungen einer IP zum Server doch recht viel. Was wäre denn hier ein relistischer Durchschnittswert, damit ich einschätzen kann, ob ich mit der Vermutung richtig liege? Kann es daran liegen, dass diese IPs und die Anzahl der Verbindungen diese load erzeugen?
 
Last edited by a moderator:
Na dann schau dir doch mal an was diese IPs denn für URLs aufrufen, wird wohl immer die Gleiche sein. Schau dir auch mal die User-Agents bzw. das angegebe OS der Requests an, bei den DDoS Angriffen die ich erlebt habe war es immer etwas exotisches, eigentlich immer "Win98".
z.B.:
.
Code:
cat /path/to/access.log | grep "144.85.154.29" > result.txt

Natürlich ist die URL nicht jedes Mal die Gleiche bei jedem Request, wenn auf der aufgerufenen Site 50 Bilder sind dann werden diese natürlich auch jedes Mal nacheinander geladen, ergo hättest du dann erst einmal 50 verschiedene Requests von einer IP bis es sich wiederholt....also auf Muster achten.
 
Last edited by a moderator:
Vielen Dank für die vielen guten Tips. Der letzte Hinweis brachte die Lösung.
Die Zugriffe waren alle legitim, d.h. kein Angriff. Es sieht im Moment so aus, dass das Wer-ist-Online-Modul mit Ajax-Funktionaliät diese Last erzeugt, wenn entsprechend User online sind und es sich ca. alle 60 Sekunden aktualisiert. Wenn ich es deaktiviere, dann fällt die Load sofort drastisch. Dann muss ich mal die Einstellungen dieses Moduls durchgehen.
 
Bei 0.5 Sekunden je Anfrage und einem Update-Intervall von 60 Sekunden waeren das realistisch 18000 gleichzeitige Besucher...

Ich predige es als Juenger der entsprechenden Programme immer und ewig aber eine Kombination aus Memcached, Lighttpd und Tracking-Daemon sollte dein Problem -zumindest teilweise- beheben.
 
Danke für das Posting. Das hat bei mir noch mal die grauen Zellen angeworfen und ich glaube ich habe einen Denkfehler in der ganzen Geschichte. Der Apache ist sozusagen doppelt belastet. Er liefert nämlich nicht nur Joomla Content aus sondern anscheinend noch ein paar andere Dinge was mir gar nicht so klar war, die wohl auf direkten Requests beruhen. Zwar ist das Joomla mit xcache schon etwas optimiet, aber für die direkten Requests, von z.B. images nützt das natürlich nichts.

aber eine Kombination aus Memcached, Lighttpd und Tracking-Daemon sollte dein Problem -zumindest teilweise- beheben.

Vielleicht macht es Sinn einen Lighttpd für die direkten Anfragen zu installieren um das dem Apache abzunehmen. Zunächst werde ich mir allerdings mal die Caching Optionen vom Apache anschauen und sehen ob das eine Verbesserung bringt. Ich werde mal den mem_cache aktivieren.
 
Deine vorherige Feststellung bez. Problemloesung durch Deaktivieren des Ajax-Inhalts sollte weiter verfolgt werden.

Ist der Ajax-Inhalt Schuld an der Misere oder macht er den kleinen aber feinen Unterschied zwischen 'benutzbar' und 'unbenutzbar'?

Sollte er Schuld sein; was genau macht der Ajax-Code? Liest er eine Datenbank aus, ...? Wie weit liesse sich die entsprechende Methode weiter optimizieren (zb komplett Datenbankfrei mit einem Tracking-Daemon im Hintergrund)?


Vielleicht macht es Sinn einen Lighttpd für die direkten Anfragen zu installieren um das dem Apache abzunehmen
Gibt es einen speziellen Grund nicht direkt alles dem Apache abzunehmen (lighttpd mit fastcgid) und diesen in den Ruhestand zu setzen - zumindest was diese eine (Sub)seite angeht? Kann der statische Inhalt in ein tmpfs verlegt werden?
 
Das sind ein paar gute Fragen, ich versuche sie mal zu beantworten.

Ich glaube es kommen mehrere Dinge hier zusammen. Ich habe gelesen, dass diese Onlinemodule sowieso lastkritisch sind. Mein Onlinemodule wurde zusätzlich um eine Ajaxfunktion erweitert, die in einstellbaren zeitlichen Abständen eine Datei ausliest und deren Inhalt anzeigt.

Mein top zeigt inzwischen eine deutliche Entspannung. Ich habe die apache conf auch noch einmal den veränderten Gesichtspunken angepasst.
Code:
top - 17:24:50 up 93 days, 15:22,  1 user,  load average: 0.21, 0.61, 2.06
Tasks: 228 total,   1 running, 227 sleeping,   0 stopped,   0 zombie
Cpu(s):  9.2%us,  2.0%sy,  0.0%ni, 88.2%id,  0.2%wa,  0.0%hi,  0.5%si,  0.0%st
Mem:   4043580k total,  1986844k used,  2056736k free,   213308k buffers
Swap:  1999928k total,    10332k used,  1989596k free,   665264k cached

Das sieht schon soviel besser aus. Ich spiele mit dem Gedanken mit lighttpd. Ich muss mich aber erst noch damit beschäftigen ob insbesondere Joomla und die SEF Komponenten und die htaccess direktiven alle so laufen wie sie sollen. Ich habe mich damit einfach noch nicht beschäftigt. Ich weiß nur, dass lighttpd einfach viel weniger Ressouren verbraucht und leistungsfähiger für größere Projekte ist. Das ist sehr interessant. Ich werde es aber eher bei einem Serverumzug in Angriff nehmen, als das jetzige System umzustellen.

Ist Ajax schuld? Ich habe das Intervall eben wieder auf 60 Sek umgestellt. Ich muss das eine Weile laufen lassen um sehen zu können, wie es sich auswirkt.

Interessanterweise hat sich diese extrem hohe Load von gestern nur wenig auf die Benutzbarkeit ausgewirkt. Das hat mich doch überrascht mit einer CPU nahe 100% und Loadaverages zwischen 60 und 150. Und die Seiten wurden trotzdem ausgeliefert. DAS verstehe ich eigentlich überhaupt nicht.
 

Um genau soetwas geht es dabei. Ich habe einiges an Rewrites und access restrictions über htaccess realisiert, da muss ich erst sicher sein, ob das wie gewünscht funktionoert.
Als SEF Komponente nutze ich Joomsef. Das ist dann das nächste Fragezeichen.

Mit eingeschaltetem Ajax sieht es inzwischen so aus:

Code:
top - 18:24:36 up 93 days, 16:21,  1 user,  load average: 0.90, 1.56, 3.49
Tasks: 171 total,   2 running, 168 sleeping,   0 stopped,   1 zombie
Cpu(s):  9.0%us,  2.0%sy,  0.0%ni, 88.5%id,  0.3%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   4043580k total,  1867740k used,  2175840k free,   215412k buffers
Swap:  1999928k total,    10332k used,  1989596k free,   714704k cached
 
Interessanterweise hat sich diese extrem hohe Load von gestern nur wenig auf die Benutzbarkeit ausgewirkt. Das hat mich doch überrascht mit einer CPU nahe 100% und Loadaverages zwischen 60 und 150. Und die Seiten wurden trotzdem ausgeliefert. DAS verstehe ich eigentlich überhaupt nicht.

Die CPU-Auslastung an sich ist im ersten Schritt nicht mit schlechter Performance gleichzusetzen. Der Zusammenhang besteht darin, dass bei einer höheren Auslastung die Wahrscheinlichkeit einer in dem Moment bereits belegten CPU größer ist und die Wartezeit dann zur Antwortzeit dazukommt. Der Effekt ist bei wenigen CPUs/Cores deutlich größer, als wenn mehr CPUs/Cores zur Verfügung stehen. Wieviel Cores hast du denn?

Ein Beispiel: angenommen ein Request dauert auf einer unbelasteten Maschine 10ms.

Bei einer 1-Core Maschine hast du rechnerisch mit 98 Requests/Sekunde eine CPU-Auslastung von 98%. Dabei entsteht jedoch soviel Wartezeit, dass der einzelne Request nun erst nach 500ms zurückkommt.

Bei einer 8-Core Maschine werden die 98% CPU-Auslastung bei etwas über 780 Requests/Sekunde erreicht und selbst dann hat jeder Request immer noch eine Antwortzeit von etwa 60ms.

Soweit zumindest die Mathematik dazu...
 
In dem Server ist ein Dualcore Prozessor.
Hmmm. Ich habe mich auf die Loadaverages bezogen. Und da ist doch jede Zahl > Anzahl CPU-Cores als Überlastung zu sehen, sprich Prozesse mussten warten. Ich hatte loadaverages bis 150.00, dass muss doch bedeuten, dass erheblich mehr Prozesse auf ihre Abarbeitung gewartet haben als die CPU bewältigen konnte.
 
In dem Server ist ein Dualcore Prozessor.
Hmmm. Ich habe mich auf die Loadaverages bezogen. Und da ist doch jede Zahl > Anzahl CPU-Cores als Überlastung zu sehen, sprich Prozesse mussten warten. Ich hatte loadaverages bis 150.00, dass muss doch bedeuten, dass erheblich mehr Prozesse auf ihre Abarbeitung gewartet haben als die CPU bewältigen konnte.

Gerade bei Linux ist das Load > CPUs = :-( so nicht allgemeingültig. Bei Linux werden beispielsweise die auf Disk-I/O wartenden Prozesse im Load mitgezählt. Während dieser Zeit ist die CPU jedoch frei für andere Prozesse. Ob das bei dir der Fall war, läßt sich aus den geposteten Daten nicht ableiten: das einen Hinweis gebende %wa im Top ist hier Null und das liegt daran, dass die CPU bei 100% war.

Wegen die Art der Berechnung (Load ist ein gedämpft zeitabhängige Durchschnitt) und auch dem relativ groben Zeitraster der Messung (nur einmal alle 5 Sekunden) verlasse ich mich jedenfalls lieber auf andere Werte. Wenn du das Paket sysstat installiert hast, dann liefert sar -q 1 0 einen guten Vergleich zwischen den Load-Werten und der tatsächlichen Länge der Queue in dem Moment.
 
Das ist eine interessante Information. Vielen Dank. Es würde auch erklären, warum das System trotz massiver Überlastungsanzeige immer noch funktionoiert hat. Dia Aussagekraft der load averages wäre in diesem Fall tatsächlich gering. Die Frage ist dann in welchem Ausmaß eine Optimierung überhaupt notwendig ist. Oder ob erst weitere Parameter, z.B. wa/id oder swap hinzukommen müssen, um von einem overload zu sprechen.
 
Eine hohe Load-AVG (bsp 15min) bedeutet dass das System viel zu tun hat und/oder ein Flaschenhals (Netzwerk, Festplatte) besteht.
Ihn zu druecken sollte in jedem Fall gut sein, da er doch, wenn auch nicht genau, aussagt dass deine System alles andere als schlafen tut.
Wenn ein Linux-System mit swappen anfaengt ist defintiv dringender Handlungsbedarf angesagt - dann geht ihm naemlich schnell die Puste aus ;)
 
Back
Top