Server "Schluckauf"? Oder einfach nur am ende...

[cronet]

Hallo,

ich hätte mal ne Frage. Wenn Sie zuwenig Tiefgang hat oder unerwünscht ist, dann einfach löschen. (es handelt sich auch nicht um einen Rootserver)

Folgendes:
Ich habe das Gefühl das mein Server so etwas wie 'Schluckauf hat'.

Es ist nicht unbedingt ein spezieller Dienst, auch nicht eine spezielle Zeit (deswegen schließe ich auch ein Cron Skript aus).

Es ist nur so, wenn ich manchmal eine Website aufrufe, dann dauert es ca. 10-15 sekunden bis die Anfrage verarbeitet wird (wenig Content, kein SQL).
Genauso bei SSH. Ich starte Putty, und es dauert bis er mir den Login abietet. Ich schreibe etwas in die Shell, und es dauert bis es angezeigt wird.

Das ist nicht immer so. Manchmal ist es so dass alles sofort passiert. Oft (leider immer öfter) aber auch nicht.

Jetzt meine Frage: Ist der Server schon am Ende? Wieviel Load ist denn 'normal'?
Das ist mein einziger Server, deswegen habe ich auch keine Vergleichswerte..

Zum Server:

Code: Select all

 	CPU Model  	Intel(R) Pentium(R) 4 CPU 2.40GHz
  	CPU MHz 	2411.66
  	CPU Cache 	512 KB


Cpu(s):   0.0% user,  50.5% system,   0.0% nice,  49.5% idle
Mem:    905356k total,   899240k used,     6116k free,     3696k buffers
Swap:   489972k total,    70956k used,   419016k free,   659872k cached

Der Load variiert zwischen 0.xx und 6.xx
Es gibt nen Tag da bewegt sich alles um 0.xx, und es gibt nen Tag da ist alles auf 3.x und natürlich Tage an denen alle Variationen dabei sind... (das Problem besteht ständig.. auch wenn Load 0.xx beträgt)

Installiert sind nur die nötigsten Sachen (Apache, PHP4, MySQL4, Postfix, Spamassassin/ClamAV, Courier) aus der aktuellen Debian/Sarge.

Es sind ca. 20 Domains auf den Server geschaltet, 11 MySQL Datenbanken, ca. 60 Mailuser.
Traffic beträgt ca. 5,5 GB/Monat.

Hoffe Ihr könnt mir einen Tipp geben.

Viele Grüße,
cronet

[svenk]

Mem: 905356k total, 899240k used, 6116k free, 3696k buffers

Keine ahnung was des sein könnte aber hast du 1GB ram? Vergessen High Memory Support in Kernel zu kompilieren? werden ja nicht komplett angezeigt.

[fhilgers]

Ok den Witz versteh ich nun nicht

Du gibst an es sei kein Rootserver, allerdings hast du da Domains drauf gehostet, was isses denn dann?

Managed? Dann hast du damit ja nichts zu schaffen
VServer? Dann falsches Forum da hier nur um Rootserver geht
HomePC? Sehr abwägig da du einige domains drauf liegen hast

Wenn Du dne Server bei dem Anieter mit der 4 im namen hast, dann ist das ein Problem das ich schon häufig gehötrt habe im bezug auf deren Server.

Also am Limit dürfte der Server damit normalerweise nicht gerade sein, wenn du da keien AMoklaufenden Scripte oder dergleichen drauf hast.

Lahmt der denn nur beim Ausliefern vom Content, oder lahmt er auch bei Ping anfragen?

[cronet]

Auszug aus demsg:

Code: Select all

Memory: 905104k/917504k available (1091k kernel code, 12016k reserved, 116k data, 252k init, 0k highmem)

Mit "es ist kein Rootserver" meinte ich dass es ein eigener Server ist (der mir gehört) und ein Housing angebot eines Unternehmens nutzt. Es ist kein Dedicated Server.

[cronet]

Richtig viel weitergekommen bin ich immer noch nicht, und mein Problem existiert weiterhin.

Mittlerweile habe ich dass Gefühl, dass es am MySQL liegt.

Immer wenn ich den stoppe, funktioniert es eigentlich.

# mysql -V
mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i386)

Hier meine my.cnf

Code: Select all

[client]
port                  = 3306
socket                = /var/run/mysqld/mysqld.sock

#[mysqld_safe]
#err-log               = /var/log/mysql/mysql.err

[mysqld]
user                  = mysql
pid-file              = /var/run/mysqld/mysqld.pid
socket                = /var/run/mysqld/mysqld.sock
log-error             = /var/log/mysql/mysqld.err
basedir               = /usr
datadir               = /var/lib/mysql
tmpdir                = /tmp
language              = /usr/share/mysql/english
bind-address          = 127.0.0.1
port                  = 3306
server-id             = 1
skip-locking
skip-networking
skip-name-resolve
skip-external-locking
local-infile = 0
key_buffer_size = 64M
sort_buffer_size = 4M
read_buffer_size = 1M
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
max_allowed_packet = 16M
net_buffer_length = 8K
thread_stack = 128K
thread_cache = 8
table_cache = 256
query_cache_type = 1
query_cache_size = 16M
query_cache_limit = 1M
thread_concurrency = 2
skip-innodb
#innodb_buffer_pool_size = 32M
#innodb_additional_mem_pool_size = 4M
#innodb_data_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend:max:128M
#innodb_log_file_size = 8M
#innodb_log_buffer_size = 8M
#innodb_log_files_in_group = 2
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
#bdb_cache_size = 4M
#bdb_max_lock = 10000
log-slow-queries = /var/log/mysql-slow.log

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
#no-auto-rehash
#safe-updates

[isamchk]
key_buffer_size = 64M
sort_buffer_size = 4M
read_buffer_size = 1M
write_buffer_size = 1M

[myisamchk]
key_buffer_size = 64M
sort_buffer_size = 4M
read_buffer_size = 1M
write_buffer_size = 1M

[mysqlhotcopy]
interactive-timeout

Die Konfig ist soweit an die von JoeUser angeglichen.
Gibts weitere Möglichkeiten den MySQL zu tunen?

[Joe User]

Mittlerweile habe ich dass Gefühl, dass es am MySQL liegt.

Immer wenn ich den stoppe, funktioniert es eigentlich.

# mysql -V
mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i386)

Könnte an der fehlenden Optimierung liegen (i386), wahrscheinlichere Performancebremse ist allerdings Spamassassin...

[cronet]

Spamassassin wird über amavis-new aufgerufen.
Ich habe jetzt vorerst mal den spamtest deaktiviert.

Mal sehen wie es sich mit der Performance jetzt verhält..

[cronet]

Mittlerweile habe ich dass Gefühl, dass es am MySQL liegt.

Immer wenn ich den stoppe, funktioniert es eigentlich.

# mysql -V
mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i386)

Könnte an der fehlenden Optimierung liegen (i386), wahrscheinlichere Performancebremse ist allerdings Spamassassin...

hm... Hab halt die Version genommen die mir apt-get liefert...

Sollte ich auf MySQL 4.1 updaten?
Jedoch ist das auch eine i386 version.
Oder muss ich die selbst compilieren?

[Joe User]

Sollte ich auf MySQL 4.1 updaten?
Jedoch ist das auch eine i386 version.
Oder muss ich die selbst compilieren?

MySQL 4.1.x hilft Dir nicht wirklich weiter. Das Hauptproblem mit Debians MySQL liegt in den suboptimalen Compileroptionen (vgl. MySQL-Handbuch). Entweder Du deaktivierst andere Ressourcenfresser, etwa amavisd-new+spamassassin, oder Du kompilierst MySQL und alle gegen MySQL gelinkten Pakete neu.

[cronet]

Sollte ich auf MySQL 4.1 updaten?
Jedoch ist das auch eine i386 version.
Oder muss ich die selbst compilieren?

MySQL 4.1.x hilft Dir nicht wirklich weiter. Das Hauptproblem mit Debians MySQL liegt in den suboptimalen Compileroptionen (vgl. MySQL-Handbuch). Entweder Du deaktivierst andere Ressourcenfresser, etwa amavisd-new+spamassassin, oder Du kompilierst MySQL und alle gegen MySQL gelinkten Pakete neu.

hm... naja. Alle gegen MySQL gelinkten Pakete...
Irgendwie ist dann der Vorteil der Paketverwaltung auch futsch...

Ich probiers wohl erstmal mit

Code: Select all

 @bypass_spam_checks_acl

in der amavis conifg...

Danke für deine Hilfe

[metrax]

Wir hatten ein ähnliches Problem mit MySQL 4.0.24, nach dem Update auf 4.1.xx lief alles wieder wie geschmiert.

Ansonsten empfehle ich mal PHP5 und Serverstats (http://freshmeat.net/projects/serverstats/) drauf zu installieren und zu schauen zu welcher Zeit der RAM so ansteigt. Wenn es immer die selbe Zeit ist, einfach mal genau zu der Zeit das Top beobachten sortiert nach RAM-Belegung.

Damit dein System den vollem RAM erkennt musst du von Debian den SMP Kernel hernehmen.

Code: Select all

apt-get install kernel-image-2.6-686-smp

bzw wenn du nen 2.4er am laufen hast kernel-image-2.4-686-smp

[oxygen]

Hm. Also für mich klingt das eher so, als wenn da Timeouts ablaufen. z.B. ein DNS Timeout. Probier doch mal einen DNS Cache zu benutzten.

[cronet]

Wir hatten ein ähnliches Problem mit MySQL 4.0.24, nach dem Update auf 4.1.xx lief alles wieder wie geschmiert.

Ansonsten empfehle ich mal PHP5 und Serverstats (http://freshmeat.net/projects/serverstats/) drauf zu installieren und zu schauen zu welcher Zeit der RAM so ansteigt. Wenn es immer die selbe Zeit ist, einfach mal genau zu der Zeit das Top beobachten sortiert nach RAM-Belegung.

Damit dein System den vollem RAM erkennt musst du von Debian den SMP Kernel hernehmen.

Code: Select all

apt-get install kernel-image-2.6-686-smp

bzw wenn du nen 2.4er am laufen hast kernel-image-2.4-686-smp

Leider war das Update auf MySQL 4.1 (aus den apt sourcen) erfolglos. (Das Update an sich nicht, aber das Problem war nicht behoben).

Jetzt habe ich mich drangemacht und den neusten Kernel gebaut (SMP und Highmem Support auf 4 GB gestellt).

Code: Select all

# uname -r
2.6.14.2
# free -m
             total       used       free     shared    buffers     cached
Mem:          1012        992         19          0         13        825
-/+ buffers/cache:        153        858
Swap:          478          0        478

Wenigstens wird nun wirklich der volle RAM erkannt.
die 150MB mehr, lindern das Problem ein wenig. Zumindest ist das ja schonmal ein Teilerfolg !

Hm. Also für mich klingt das eher so, als wenn da Timeouts ablaufen. z.B. ein DNS Timeout. Probier doch mal einen DNS Cache zu benutzten.

Hat bind nicht eigentlich einen eigenen Cache und nutzt diesen?
Ich hab im Forum gesucht, und den hinweis auf nscd gefunden. Meintest du so etwas in der Art?

Vielleicht bleibt mir jetzt doch nichts anderes übrig als MySQL und die gelinkten Pakete neu zu bauen...

[outofbound]

Schonmal den Swap ausgeschaltet?
Nicht, dass sich die Kiste wegen hohen Speicherverbrauchs totswapt...

Was läuft denn in der SQL? Hast du da evtl. kaputte Querries drin?

Gruss,

Out

[cronet]

Schonmal den Swap ausgeschaltet?
Nicht, dass sich die Kiste wegen hohen Speicherverbrauchs totswapt...

Was läuft denn in der SQL? Hast du da evtl. kaputte Querries drin?

Gruss,

Out

Der Server swappt ja nicht. (Siehe unten vmstat ausgabe)

Code: Select all

#mysqladmin status
Uptime: 14753  Threads: 1  Questions: 20786  Slow queries: 7  Opens: 469  Flush tables: 1  Open tables: 256  Queries per second avg: 1.409

Die Slow Queries sind laut slow-query log nur UPDATED und INSERTS...

Vielleicht noch ein paar Zusatzinfos:

Code: Select all

#top
# top
top - 15:20:56 up 14:52,  2 users,  load average: 3.64, 2.51, 2.58
Tasks:  83 total,   6 running,  77 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.8% us, 45.8% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.4% hi, 52.0% si
Mem:   1036624k total,   975220k used,    61404k free,    23016k buffers
Swap:   489972k total,        4k used,   489968k free,   794140k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23586 root      17   0     0    0    0 R 45.7  0.0   0:41.34 pdflush
24034 root      15   0     0    0    0 S 30.7  0.0   0:00.91 pdflush
21836 af        15   0 14672 1412 1024 S  7.0  0.1   0:33.62 sshd
24032 root      19   0  2200  496  424 R  5.7  0.0   0:01.05 cp
24033 root      16   0  1948  952  740 R  3.1  0.1   0:01.08 top
24029 root      16   0  1648  536  452 S  0.9  0.1   0:00.92 vmstat
  639 root      16   0  1856  488  416 S  0.4  0.0   0:54.93 couriertcpd
  864 root      16   0  3316 3316 2644 R  0.4  0.3   9:22.67 ntpd
 6665 postfix   34  19  3084 1236 1016 R  0.4  0.1   0:09.08 qmgr
    1 root      16   0  1588  516  452 S  0.0  0.0   2:07.95 init
    2 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
    3 root      39  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
    4 root      10  -5     0    0    0 S  0.0  0.0   6:38.10 events/0
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khelper
    6 root      10  -5     0    0    0 S  0.0  0.0   0:08.01 kthread
    7 root      10  -5     0    0    0 S  0.0  0.0   0:43.86 kblockd/0
   11 root      17  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
   10 root      15   0     0    0    0 S  0.0  0.0   2:32.24 kswapd0
   12 root      10  -5     0    0    0 S  0.0  0.0   0:00.02 kseriod
   13 root      15   0     0    0    0 S  0.0  0.0   4:04.70 kjournald
  148 root      15   0     0    0    0 S  0.0  0.0   0:00.12 kjournald
  149 root      16   0     0    0    0 S  0.0  0.0 157:54.96 kjournald
  150 root      16   0     0    0    0 S  0.0  0.0   2:13.24 kjournald
  535 root      15   0  1632  540  440 S  0.0  0.1   0:49.80 syslogd
  538 root      16   0  2252 1096  348 S  0.0  0.1   0:00.17 klogd
  546 bind      18   0 31480 3508 1824 S  0.0  0.3   3:07.51 named
  557 amavis    16   0 16408  13m 1540 S  0.0  1.4   2:20.73 amavisd-new
  571 clamav    17   0 28628 9400  920 S  0.0  0.9   0:08.51 clamd
  612 clamav    16   0  4164  920  688 S  0.0  0.1   0:00.28 freshclam

Code: Select all

#vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 4  0      4  14140  22892 843156    0    0   173   612  462    53  4 45 47  5
 4  0      4  14140  22900 843148    0    0     0  4136  829    12  0 100  0  0
 4  0      4  13576  22900 842604    0    0    16 10240 1018    53 13 87  0  0
 3  1      4  13264  22908 842868    0    0   104   644 1217   208 33 66  0  1
 6  1      4  13448  22912 841980    0    0   260  5240 1141   107  3 84  0 13
 4  0      4 107004  22936 749068    0    0   864  2152  718    66  1 95  0  4
 3  0      4 102952  22940 753144    0    0     0  3532  721    17  1 99  0  0
 2  0      4 102828  22948 753476    0    0     0  3376  682    23  0 100  0  0
 6  3      4  94636  22960 761352    0    0    36  4880 1008    35  0 100  0  0
 3  2      4  89552  22976 766640    0    0    28  6916  749    57 15 85  0  0
 2  1      4  88436  22988 767648    0    0     0   108  676    88 11 89  0  0
 4  1      4  69836  23008 785988    0    0     4  3164  673    50  4 96  0  0
 5  1      4  61404  23016 794140    0    0     0  3920  805    56  2 98  0  0
 4  2      4  54460  23036 800988    0    0     4  3980  829    55  1 99  0  0
 3  1      4  54460  23036 800988    0    0     0  4096  819    12  0 100  0  0
 5  1      4  54460  23036 800988    0    0     0  4096  826    11  5 95  0  0
 3  1      4  53840  23040 802004    0    0     4 19944  818    34 23 77  0  0

Code: Select all

# pstree
init─┬─amavisd-new───2*[amavisd-new]
     ├─apache2───10*[apache2]
     ├─atd
     ├─clamd
     ├─courierlogger───authdaemond.pla───5*[authdaemond.pla]
     ├─2*[courierlogger]
     ├─2*[couriertcpd]
     ├─cron─┬─cron───sh───vhcs2-vrl-traff───sh─┬─diff
     │      │                                  └─sh
     │      └─cron───sh───vhcs2-httpd-log───cp
     ├─events/0
     ├─freshclam
     ├─6*[getty]
     ├─inetd
     ├─khelper
     ├─4*[kjournald]
     ├─klogd
     ├─ksoftirqd/0
     ├─kswapd0
     ├─kthread─┬─aio/0
     │         ├─kblockd/0
     │         ├─kseriod
     │         └─2*[pdflush]
     ├─master─┬─pickup
     │        └─qmgr
     ├─migration/0
     ├─mysqld_safe───mysqld
     ├─named
     ├─nscd
     ├─ntpd
     ├─proftpd
     ├─sshd─┬─sshd───sshd───bash───su───bash
     │      └─sshd───sshd───bash───su───bash───pstree
     ├─syslogd
     └─vhcs2_daemon

[cronet]

Leider hat sich mein problem nur marginal verbessert.

Load ist zwar etwas runtergegangen und das System fühlt sich auf der Konsole nicht so zäh an.

Leider werden die Webseiten, auch bei Seiten ohne MySQL, sehr langsam ausgeliefert. Sie sind dann zwar sofort da, aber erst sekunden später...

Ich werde wohl jetzt nach debianhowto php5 mit fastcgi installieren und dann serverstats fürs logging verwenden... und dann mal kucken...

Was anderes fällt mir jetzt im Moment auch nicht mehr ein...

[cronet]

Sollte ich auf MySQL 4.1 updaten?
Jedoch ist das auch eine i386 version.
Oder muss ich die selbst compilieren?

MySQL 4.1.x hilft Dir nicht wirklich weiter. Das Hauptproblem mit Debians MySQL liegt in den suboptimalen Compileroptionen (vgl. MySQL-Handbuch). Entweder Du deaktivierst andere Ressourcenfresser, etwa amavisd-new+spamassassin, oder Du kompilierst MySQL und alle gegen MySQL gelinkten Pakete neu.

Du hattest natürlich Recht !!

Ein update auf Debian MySQL 4.1 war sinnlos.

Das einzige was half, war MySQL neu zu kompilieren.
Mit allen Performance tuning optionen die ich finden konnte...
Und alles statisch verlinkt.

Ergebnis: Superschneller MySQL Server.

Schluckauf weg,
alles sehr performant... !!

Ich bin gespannt obs so bleibt... Aber ich denke schon!!

Danke an alle die mir geholfen haben und v.a. JoeUser der mir den richtigen Anstoss gab!!

Viele Grüße,
Alex (sichtlich erleichtert)