Serverlast viel zu hoch bei User > 250

[tobiask]

Hallo,

wenn in unserem WBB1.2 Board mehr als ~250 User gleichzeitig online sind ist der server unendlich lahm und reagiert kaum noch ...

system ist:
Intel Celeron 2.400 MHz-Prozessor
512 MB DDR-RAM

ich denke der prozessor/ram is zu klein oder ?!
oder gibt es eine möglichkeit wie ich das forum optimieren kann, oder die mysql conn verbessern kann?

my.cnf (ohne kommentare):

Code: Select all

[client]
port            = 3306
socket          = /var/lib/mysql/mysql.sock

[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 16M
max_allowed_packet = 1M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
myisam_sort_buffer_size = 8M
query_cache_size=16M
query_cache_limit=512K
query_cache_type=1

server-id       = 1

[safe_mysqld]
err-log=/var/lib/mysql/mysqld.log

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

[sir tom]

Naja, ein Celeron als Datenbankserver ist nicht gerade das Optimum, da kommt man schnell an die Grenzen.

Ich hab HLStats von 6 Servern die in eine mySQL DB loggen die auf nem P3-700 liegt, da is auch noch ein Forum drauf und ein paar Webseiten, die Kiste läuft rund. Auf einem Celeron ging das (2GHz Celi mit 512MB) in die Hose...

[andreask2]

Hm, hier im Forum gibt es einige Diskussionen zum Thema.

Als erstes wäre mal die Ausgabe von top ganz hilfreich.

Vielleicht mal drüber nachdenken einen PHP Opcode Cache zu verwenden, wie PECL::APC oder Zend Cache.

Vielleicht auch mal mit hdparm gucken ob die Festplatten-Zugriffe nicht künstlich gebremst werden...

Und sonst mal in die anderen Threads hier im Forum gucken.

[andreask2]

ach Du hast ja schon den ein oder anderen Thread zum Thema gestartet, naja.

Mit

Code: Select all

top -b -n1

erhälst Du eine vollständige Liste der Prozesse.

[tobiask]

cache hab ich schon drauf, turck mmcache.

top sagt:

Code: Select all

11105 mysql     20   0 34248  33m 2880 R 21.3  6.8   2:56.46 mysqld
17425 mysql     15   0 34248  33m 2880 R 18.5  6.8   0:00.13 mysqld
10194 mysql     20   0 34248  33m 2880 R 17.1  6.8   4:04.83 mysqld
16849 mysql     20   0 34248  33m 2880 R 17.1  6.8   0:17.58 mysqld
17419 root      15   0   988  988  760 R 11.4  0.2   0:00.18 top
17426 mysql     18   0 34248  33m 2880 R 11.4  6.8   0:00.08 mysqld
17423 wwwrun    13   0 13332  13m  12m S  5.7  2.6   0:00.04 httpd2-prefork
17420 wwwrun    11   0 13408  13m  12m S  4.3  2.6   0:00.03 httpd2-prefork
17421 wwwrun    11   0 13308  12m  12m S  1.4  2.6   0:00.01 httpd2-prefork
    1 root       8   0   252  240  220 S  0.0  0.0   0:43.87 init
    2 root       9   0     0    0    0 S  0.0  0.0   0:00.00 keventd
    3 root      19  19     0    0    0 S  0.0  0.0   0:01.15 ksoftirqd_CPU0
    4 root       9   0     0    0    0 S  0.0  0.0   0:19.09 kswapd
    5 root       9   0     0    0    0 S  0.0  0.0   0:00.00 bdflush
    6 root       9   0     0    0    0 S  0.0  0.0  10:14.08 kupdated
    7 root       9   0     0    0    0 S  0.0  0.0   0:34.28 pagebufd
    8 root       9   0     0    0    0 S  0.0  0.0   1:07.53 xfslogd/0
    9 root       9   0     0    0    0 S  0.0  0.0   0:00.00 xfsdatad/0
   11 root       9   0     0    0    0 S  0.0  0.0   1:33.96 kjournald
   56 root       9   0     0    0    0 S  0.0  0.0   0:01.88 xfssyncd
   57 root       9   0     0    0    0 S  0.0  0.0   0:13.54 xfssyncd
   58 root       9   0     0    0    0 S  0.0  0.0   0:08.23 xfssyncd
  423 root       9   0   544  532  476 S  0.0  0.1   0:00.01 dhcpcd
  489 root       9   0   624  624  532 S  0.0  0.1   1:09.26 syslogd
  492 root       9   0  1516 1516  472 S  0.0  0.3   0:00.46 klogd
  521 root       9   0  1408 1324 1100 S  0.0  0.3   0:00.17 saslauthd
  526 root       9   0  1408 1324 1100 S  0.0  0.3   0:00.27 saslauthd
  527 root       9   0  1408 1324 1100 S  0.0  0.3   0:00.20 saslauthd
  528 root       9   0  1408 1324 1100 S  0.0  0.3   0:00.17 saslauthd
  540 root       9   0  1408 1324 1100 S  0.0  0.3   0:00.14 saslauthd
  701 root       8   0   840  776  712 S  0.0  0.2   0:54.61 xinetd
  757 ntp        9   0  2184 2184 1872 S  0.0  0.4   2:40.82 ntpd
  784 spamd      8   0 23960  14m 2432 S  0.0  2.9   0:21.48 spamd
  788 root       9   0  1356 1216 1096 S  0.0  0.2   1:55.76 master
  849 root       9   0   716  704  620 S  0.0  0.1   0:16.80 cron
  866 root       9   0   636  560  560 S  0.0  0.1   0:00.04 mingetty
  867 root       9   0   636  560  560 S  0.0  0.1   0:00.04 mingetty
  868 root       9   0   476  428  428 S  0.0  0.1   0:00.00 agetty
23323 root       9   0  1292 1292 1088 S  0.0  0.3   0:00.01 pipelog.pl
19245 root       9   0  1768 1768 1608 S  0.0  0.3   0:05.37 sshd
20154 root       9   0  1292 1292 1088 S  0.0  0.3   0:00.02 pipelog.pl
26943 uucp       9   0   972  960  780 S  0.0  0.2   0:00.58 avgated
26946 uucp       9   0  1004  992  888 S  0.0  0.2   0:00.02 avgatefwd
26947 uucp       8   0   988  976  900 S  0.0  0.2   0:12.73 avgatefwd
26948 uucp       9   0   988  976  900 S  0.0  0.2   0:04.36 avgatefwd
14716 root      14   0 12520  12m  12m S  0.0  2.5  12:48.30 httpd2-prefork
15501 postfix    9   0  1412 1412 1128 S  0.0  0.3   0:02.73 qmgr
 1806 root       9   0  1200 1196  984 S  0.0  0.2   0:00.06 mysqld_safe
 1838 mysql      9   0 34248  33m 2880 S  0.0  6.8   0:26.38 mysqld
 1839 mysql     16   0 34248  33m 2880 S  0.0  6.8   0:29.00 mysqld
 1840 mysql      9   0 34248  33m 2880 S  0.0  6.8   0:22.11 mysqld
19780 root       9   0  1360 1360 1152 S  0.0  0.3   0:00.21 pipelog.pl
19786 root       9   0 12516  12m  12m S  0.0  2.5   0:00.00 httpd2-prefork
 8013 uucp      10   1  4672 4672  704 S  0.0  0.9   0:00.03 antivir
32164 postfix    9   0  1360 1360 1108 S  0.0  0.3   0:00.03 pickup
10189 wwwrun     9   0 14476  14m  12m S  0.0  2.9   0:01.65 httpd2-prefork
11088 wwwrun     9   0 14564  14m  12m S  0.0  2.9   0:01.19 httpd2-prefork
15608 web1p11    9   0  1756 1752 1344 S  0.0  0.3   0:00.05 popper
16837 wwwrun     9   0 13984  13m  12m S  0.0  2.8   0:00.18 httpd2-prefork
16909 postfix    9   0  2504 2504 1912 S  0.0  0.5   0:00.03 smtpd
16910 postfix    9   0  1304 1304 1060 S  0.0  0.3   0:00.01 proxymap
16911 postfix    9   0  1804 1804 1376 S  0.0  0.4   0:00.04 cleanup
16912 postfix    9   0  2496 2496 1912 S  0.0  0.5   0:00.02 smtpd
16916 postfix    9   0  1744 1744 1324 S  0.0  0.3   0:00.02 trivial-rewrite
16917 postfix    9   0  1804 1804 1376 S  0.0  0.4   0:00.03 cleanup
17006 wwwrun     9   0 12580  12m  12m S  0.0  2.5   0:00.00 httpd2-prefork
17037 postfix    9   0  1496 1492 1212 S  0.0  0.3   0:00.02 smtp
17073 wwwrun     9   0 12580  12m  12m S  0.0  2.5   0:00.00 httpd2-prefork
17117 wwwrun     9   0 12844  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17186 wwwrun     9   0 12844  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17216 wwwrun     9   0 12700  12m  12m S  0.0  2.5   0:00.03 httpd2-prefork
17223 wwwrun     9   0 12852  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17243 wwwrun     9   0 12844  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17249 wwwrun     9   0 13060  12m  12m S  0.0  2.6   0:00.05 httpd2-prefork
17256 wwwrun     9   0 12852  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17266 wwwrun     9   0 12844  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17294 wwwrun     9   0 13296  12m  12m S  0.0  2.6   0:00.05 httpd2-prefork
17295 wwwrun     9   0 12844  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17296 wwwrun     9   0 12844  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17297 root       8   0     0    0    0 Z  0.0  0.0   0:00.00 cron <defunct>
17300 wwwrun     9   0 13276  12m  12m S  0.0  2.6   0:00.06 httpd2-prefork
17301 wwwrun     9   0 12688  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17303 wwwrun     9   0 13028  12m  12m S  0.0  2.6   0:00.02 httpd2-prefork
17305 wwwrun     9   0 13028  12m  12m S  0.0  2.6   0:00.04 httpd2-prefork
17311 wwwrun     9   0 12688  12m  12m S  0.0  2.5   0:00.00 httpd2-prefork
17317 wwwrun     9   0 13428  13m  12m S  0.0  2.6   0:00.01 httpd2-prefork
17319 wwwrun     9   0 12688  12m  12m S  0.0  2.5   0:00.00 httpd2-prefork
17322 wwwrun     9   0 13028  12m  12m S  0.0  2.6   0:00.03 httpd2-prefork
17323 wwwrun     9   0 13428  13m  12m S  0.0  2.6   0:00.03 httpd2-prefork
17324 wwwrun     9   0 12688  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17337 wwwrun     9   0 13000  12m  12m S  0.0  2.6   0:00.02 httpd2-prefork
17340 root       9   0  2368 2364 2060 S  0.0  0.5   0:00.03 sshd
17344 wwwrun     9   0 13536  13m  12m S  0.0  2.7   0:00.06 httpd2-prefork
17350 wwwrun     9   0 13276  12m  12m S  0.0  2.6   0:00.06 httpd2-prefork
17351 wwwrun     9   0 13032  12m  12m S  0.0  2.6   0:00.01 httpd2-prefork
17356 wwwrun     9   0 12688  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17357 wwwrun     9   0 14600  14m  12m S  0.0  2.9   0:00.18 httpd2-prefork
17358 wwwrun     9   0 12852  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17364 wwwrun     9   0 13280  12m  12m S  0.0  2.6   0:00.05 httpd2-prefork
17367 root       8   0  2368 2364 2060 S  0.0  0.5   0:00.00 sshd
17369 wwwrun     9   0 13036  12m  12m S  0.0  2.6   0:00.03 httpd2-prefork
17370 wwwrun     9   0 13120  12m  12m S  0.0  2.6   0:00.02 httpd2-prefork
17372 wwwrun     9   0 13412  13m  12m S  0.0  2.6   0:00.02 httpd2-prefork
17374 wwwrun     9   0 12692  12m  12m S  0.0  2.5   0:00.00 httpd2-prefork
17376 wwwrun     9   0 13204  12m  12m S  0.0  2.6   0:00.04 httpd2-prefork
17379 wwwrun     9   0 13300  12m  12m S  0.0  2.6   0:00.04 httpd2-prefork
17382 wwwrun     9   0 13000  12m  12m S  0.0  2.6   0:00.02 httpd2-prefork
17384 wwwrun     9   0 12844  12m  12m S  0.0  2.5   0:00.02 httpd2-prefork
17397 root       9   0  1760 1760 1312 S  0.0  0.3   0:00.04 bash
17411 wwwrun     9   0 13028  12m  12m S  0.0  2.6   0:00.03 httpd2-prefork
17417 wwwrun     9   0 12692  12m  12m S  0.0  2.5   0:00.01 httpd2-prefork
17418 wwwrun     9   0 12904  12m  12m S  0.0  2.5   0:00.02 httpd2-prefork
17422 wwwrun    11   0 12692  12m  12m S  0.0  2.5   0:00.00 httpd2-prefork

[andreask2]

Hm, der Apache ist sehr klein, der SHM-Anteil ist ja sehr groß (und der muss nur einmalig gerechnet werden).

Bei MySQL ist es genau umgekehrt. Ein kleiner SHM-Bereich, aber trotzdem riesen große Prozesse. Bei mir ist das ähnlich, und ich verstehe ehrlich gesagt nicht wirklich wieso das so ist, denn eigentlich müssten die großen Cache-Bereiche wie Query-Cache ja als SHM einen recht großen Anteil einnehmen.
Würde mich mal sehr interessieren wieso das Verhältnis von Prozessgröße zu SHM bei MySQL eigentlich immer so seltsam ist - woher kommt das, oder interpretiere ich die Anzeige falsch?

[tobiask]

Hm, der Apache ist sehr klein, der SHM-Anteil ist ja sehr groß (und der muss nur einmalig gerechnet werden).

Bei MySQL ist es genau umgekehrt. Ein kleiner SHM-Bereich, aber trotzdem riesen große Prozesse. Bei mir ist das ähnlich, und ich verstehe ehrlich gesagt nicht wirklich wieso das so ist, denn eigentlich müssten die großen Cache-Bereiche wie Query-Cache ja als SHM einen recht großen Anteil einnehmen.
Würde mich mal sehr interessieren wieso das Verhältnis von Prozessgröße zu SHM bei MySQL eigentlich immer so seltsam ist - woher kommt das, oder interpretiere ich die Anzeige falsch?

hmm, weiß ich auch nicht genau,
aber hdparm hat folgendes gebracht:

Code: Select all

~: hdparm -Tt /dev/hda

/dev/hda:
 Timing buffer-cache reads:   376 MB in  2.04 seconds = 184.31 MB/sec
 Timing buffered disk reads:  108 MB in  3.03 seconds =  35.64 MB/sec

~: hdparm -i /dev/hda

/dev/hda:

 Model=ST380011A, FwRev=3.54, SerialNo=5JT1RJA6
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=156301488
 IORDY=on/off, tPIO={min:240,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: ATA/ATAPI-6 T13 1410D revision 2:

 * signifies the current active mode

was kann man da noch verbessern?

[andreask2]

Wenn überhaupt, dann nicht besonders viel denke ich.

Was sagt denn

Code: Select all

hdparm /dev/hda

Wenn Du besonders hohe Last hast könntest Du mal

Code: Select all

vmstat 5

ne Zeit lang mitlaufen lassen, das ist manchmal auch ganz interessant.

[tobiask]

Wenn überhaupt, dann nicht besonders viel denke ich.

Was sagt denn

Code: Select all

hdparm /dev/hda

Wenn Du besonders hohe Last hast könntest Du mal

Code: Select all

vmstat 5

ne Zeit lang mitlaufen lassen, das ist manchmal auch ganz interessant.

hdparm /dev/hda:

Code: Select all

/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 9729/255/63, sectors = 156301488, start = 0

[andreask2]

hab ich eigentlich genau so stehen, wenn Du das jetzt während des Betriebs auf einem so oder so überlasteten Server gemacht hast sind die Ergebnisse eh etwas untertrieben.

Naja, wenn man sich die CPU-Auslastung nochmal ansieht, dann lastet MySQL die CPU fast im Alleingang komplett aus. Das spricht IMHO dafür dass Du entweder eine Software hast die ein sehr ineffektives DB-Design verwendet, bzw. sehr ineffektive SQL-Queries, oder wenn das alles wunderbar ist, dann entsteht bei der Anzahl an Usern nunmal so viel Last, dass Du ein größere Maschine brauchst. Eine deutlich größere, das heißt kein Celeron mehr, am besten einen schönen dual-Xeon oder Opteron ;-)

[tobiask]

hab ich eigentlich genau so stehen, wenn Du das jetzt während des Betriebs auf einem so oder so überlasteten Server gemacht hast sind die Ergebnisse eh etwas untertrieben.

Naja, wenn man sich die CPU-Auslastung nochmal ansieht, dann lastet MySQL die CPU fast im Alleingang komplett aus. Das spricht IMHO dafür dass Du entweder eine Software hast die ein sehr ineffektives DB-Design verwendet, bzw. sehr ineffektive SQL-Queries, oder wenn das alles wunderbar ist, dann entsteht bei der Anzahl an Usern nunmal so viel Last, dass Du ein größere Maschine brauchst. Eine deutlich größere, das heißt kein Celeron mehr, am besten einen schönen dual-Xeon oder Opteron ;-)

ich denke die sql sachen kommen vom wbb, hat damit jenmand erfahrung?

neuer server is zurzeit leider zu teuer :?

[andreask2]

Ach ja, wen Du ein wirklich effektives Forum suchst kann ich das classic-forum empfehlen, das wird bei SELFHTML mehrfach eingesetzt. Verfügt über einen eigenen Forumsserver in C, der über CGI-Clients (ebenfalls C) angesprochen wird. Der Server hält aktuelle Beiträge im RAM.

http://wwwtech.de/cforum/

Ist natürlich ein Forum und kein Board ;-)

[tobiask]

Ach ja, wen Du ein wirklich effektives Forum suchst kann ich das classic-forum empfehlen, das wird bei SELFHTML mehrfach eingesetzt. Verfügt über einen eigenen Forumsserver in C, der über CGI-Clients (ebenfalls C) angesprochen wird. Der Server hält aktuelle Beiträge im RAM.

http://wwwtech.de/cforum/

Ist natürlich ein Forum und kein Board ;-)

naja, wir benötigen aber eher ein board ;)

[oxygen]

Es würde sich auf jeden Fall lohnen auf ein aktuelles Woltlab Burning Board oder direkt auf VBulletin oder Invision Power Board umzusteigen. Alle drei laufen auch unter hoher Last mit schwacher Hardware recht zügig.

[tobiask]

Es würde sich auf jeden Fall lohnen auf ein aktuelles Woltlab Burning Board oder direkt auf VBulletin oder Invision Power Board umzusteigen. Alle drei laufen auch unter hoher Last mit schwacher Hardware recht zügig.

danke, werd ich mir mal anschauen!

[odysseus]

Hallo,

wenn in unserem WBB1.2 Board mehr als ~250 User gleichzeitig online sind ist der server unendlich lahm und reagiert kaum noch ...

system ist:
Intel Celeron 2.400 MHz-Prozessor
512 MB DDR-RAM

ich denke der prozessor/ram is zu klein oder ?!
oder gibt es eine möglichkeit wie ich das forum optimieren kann, oder die mysql conn verbessern kann?

Um es kurz zu machen: Vergiss es.
Bei Woltlab werden sie dir eh nicht helfen können, weil sie zum einen selbst keine Ahnung von Servern haben (das soll keine Beleidigung sein - es ist einfach so; sie haben ja nicht mal ein Support-Forum zum Thema Serverkonfiguration), und bei vBulletin werden sie dir sagen, dass du einen Dual Xeon mit 2GB Ram und SCSI Platten brauchst.

Muit deinem Server wirst du auf wbb1.2 Basis niemals mehr als 100 gleichzeitige User bei einem 900-Sekunden Sessiontimeout tragen können, ohne massivste Performance-Einbrüch ertragen zu müssen. Celerons sind für Serveraufgaben nicht gemacht, und dank dem kleinen RAM hat MySQL nicht genug Platz und muss swappen, was wiederum die Performance nach unten peitscht.

Ein Server, der für deine 250 User angemessen wäre, ist entweder ein Athlon 64 3000+ mit 1 GB RAM oder ein Xeon 2.66 GHz. In beiden Fällen brauchst du entweder eine SCSI Platte oder zwei IDE Platten, wobei eine dediziert für die Datenbank partitioniert sein muss. (Also nur die DB wird drauf gespeichert).


Mit deinem Celeron ist es unmöglich, das Board weiterhin zu betreiben.

[andreask2]

Dass die Platten so belastet werde, das weißt Du aus Erfahrung, vermute ich, oder?

http://www.webmaster-eye.de/schranz/mysqld.jpg (aus http://www.rootforum.org/forum/viewtopic.php?t=27106)

Das sieht für mich so aus als sei es ein reines CPU-Problem, denn im Prinzip wird fast nicht geswappt. Das heißt die Plattenzugriffe entstehen vor allem beim lesen, schreiben von Tabellen denke ich jetzt mal, nur wenn hier die Patten das Problem wären, dürfte man doch eigentlich nicht 100% CPU-Last haben, sondern eher einen hochen Load, oder? Oder entsteht durch das Lesen von Platten mehr CPU-Last als vom RAM? Kann schon sein, aber dafür entstehen dabei ja viel größere Latenzzeiten, oder? So Interpretationen interessieren mich ;-)


Aber wie dem auch sei, ich würd es testweise schon mal mit einem neueren/bessere Board vergleichen, man weiß ja nie, kann ja durchaus sein dass das extrem ineffizient war was Du zur Zeit verwendest.

Und sonst hilft halt wirklich nur ein Hardware-Upgrade, und hier würde ich vor allem auf eine kräftige CPU achten, AMD Athlon 3000 ist sicher nicht schlecht, und sonst würde ich einen P4 mit möglichst viel Mhz, HT, großem L2 Cache und 800Mhz FSB nehmen. Ein Xeon muss es IMHO erst für ein Dual-System sein, oder wieso meinst Du der Xeon sei mehr geeinet? Der Xeon ist entweder langsamer, oder deutlich teurer als ein normaler P4 - AFAIK.

[odysseus]

Dass die Platten so belastet werde, das weißt Du aus Erfahrung, vermute ich, oder?

http://www.webmaster-eye.de/schranz/mysqld.jpg (aus http://www.rootforum.org/forum/viewtopic.php?t=27106)

Ja, das weiß ich aus Erfahrung.
Wie man auf der Grafik erkennen kann, brauchen die MySQL Threads verdammt lange. Das liegt daran, dass sie nicht geschrieben werden können - sei es wegen (Dead-)Locks oder wegen Ã?berlastung aus anderem Grunde.
Mir geht es derzeit sehr ähnlich, allerdings hat das Update auf vBulletin 3 hier sehr viel geholfen. Diese Version geht sehr viel schonander mit den Ressourcen um und braucht auch ca. 50% weniger Queries pro Seite. Das ist ein wichtiger Knackpunkt, und da ist das wbb1.2 leider schon viel zu veraltet und ressourcenhungrig.

Oder entsteht durch das Lesen von Platten mehr CPU-Last als vom RAM?

Naja, im DMA-Modus braucht man nicht viel CPU-Leistung für Plattenzugriffe.
RAM Zugriffe regelt der Speichercontroller.

Aber wie dem auch sei, ich würd es testweise schon mal mit einem neueren/bessere Board vergleichen, man weiß ja nie, kann ja durchaus sein dass das extrem ineffizient war was Du zur Zeit verwendest.

wbb1.2 ist wie gesagt nicht für große Communitys auf schwachen servern geeignet. Das sagt auch Woltlab und verweist auf das kostenpflichtige wbb2. (Meiner Meinung nach ist das aber immer noch zu ressourcenhungrig).

Und sonst hilft halt wirklich nur ein Hardware-Upgrade, und hier würde ich vor allem auf eine kräftige CPU achten, AMD Athlon 3000 ist sicher nicht schlecht, und sonst würde ich einen P4 mit möglichst viel Mhz, HT, großem L2 Cache und 800Mhz FSB nehmen. Ein Xeon muss es IMHO erst für ein Dual-System sein, oder wieso meinst Du der Xeon sei mehr geeinet? Der Xeon ist entweder langsamer, oder deutlich teurer als ein normaler P4 - AFAIK.

Dem stimme ich zu!

PS: Mein Hinweis, auf einen Hoster, der derzeit einen Athlon 64 im Angebot hat, wurde ja leider gelöscht. Trotzdem: Such mal danach, es GIBT einen. :)

[andreask2]

Oder entsteht durch das Lesen von Platten mehr CPU-Last als vom RAM?

Naja, im DMA-Modus braucht man nicht viel CPU-Leistung für Plattenzugriffe.
RAM Zugriffe regelt der Speichercontroller.

Aber wieso soll die CPU-Last dann mit den hohen Plattenzugriffen un Zusammenhang stehen? Wenn ein Prozess auf daten von der Platte wartet, dann macht der doch nichts, und erzeugt keine Last. Wenn die die Platten noch schneller wären würde sich ja nichts ändern weil die CPU einfach nicht mehr Daten verarbeiten kann.

Und zum RAM, heißt also dass RAM-Zugriffe in jedem Fall, trotz DMA weniger CPU koste, oder?

wbb1.2 ist wie gesagt nicht für große Communitys auf schwachen servern geeignet. Das sagt auch Woltlab und verweist auf das kostenpflichtige wbb2. (Meiner Meinung nach ist das aber immer noch zu ressourcenhungrig).

Ja, duch bessere Algorithmen lassen sich der Resourcen-Verbrauch sogar um einige Potenzen verbessern, aber das kostest meist viel Arbeit. Wenn es effizentere und komatible Versionen gibt, dann sollte man das IMHO als erstes ausschöpfen.

PS: Mein Hinweis, auf einen Hoster, der derzeit einen Athlon 64 im Angebot hat, wurde ja leider gelöscht. Trotzdem: Such mal danach, es GIBT einen. :)

Naja, die AMD64-Unterstützung von Linux leidet noch an vielen Kinderkrankheiten, es werden zwar riesige Fortschritte gemacht, aber alles in allem wäre mir persönlich das Risiko im Moment noch zu groß. Auf der anderen Seite sind die AMD64/Opterons noch lange nicht am Ende der Fahnenstange, da besteht noch ne Menge Optimierungs-Potential, was hingegen bei den P4/Xeons... schon so ziemlich ausgereizt ist (daher kommen die ja demnächst ebenfalls mit der AMD64 Erweiterunge raus ;-)).

Bei selfhtml.org werkeln ja inzwischen auch 3 dual-Opterons mit Gentoo Linux(64bit). Es funktioniert also duchaus, und auch unter Last :)

Grüße
Andreas

[streicher]

Es geht durchaus 250 User auf einem solchen Server in einem Forum haben zu können. Das geht zwar nicht optimal, aber es geht.
Wir hatten ein ähnliche Problem (2 vB's 3.0, bis zu 300 User in beiden zusammengerechnet und quasi geiche Serverausstattung CPU + RAM). Ich weiß nun nicht, wie effektiv das Woltlab Board arbeitet, aber uns hat man beim vB Support nicht zu einem schnelleren Server geraten, sondern dazu MySQL 4 und PHP > 4.34 zu installieren. Danach haben wir noch auch auf Empfehlung folgende Files auf dem Server angepasst:

my.cnf

Code: Select all

[mysqld]
socket = /var/lib/mysql/mysql.sock
skip-locking
max_connections = 300
key_buffer = 16M
myisam_sort_buffer_size = 64M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 2M
table_cache = 1024
thread_cache_size = 64
wait_timeout = 1800
connect_timeout = 10
max_allowed_packet = 16M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 16M
query_cache_type = 1
skip-innodb
#log-bin

[mysqld_safe] 
open_files_limit = 8192

[mysqldump]
quick
max_allowed_packet = 16M

[myisamchk] 
key_buffer = 64M 
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

httpd.conf: lower maxclients from 250 to 150 and restart apache


Das vB arbeitet wie von anderen erwähnt recht effektiv. man kann zusätzlich noch mal bei den Funktionen des Forums nachsehen, was davon eventuell viele Ressourcen benötigt und nicht wirklich gebraucht wird. Mit diesen obigen Ã?nderungen konnten wir die Last deutlich reduzieren, aber ich kann sagen, ob es beim einem Woltlab Board ähnliche Auswirkungen. Mittelfristig kommen aber auch wir nicht um ein Hardware-Upgrade herum, aber zumindest konnte es verzögert werden.

[tobiask]

danke, werd ich mal testen!