Ich möchte eines vorweg schicken und ich sage es - gemäß der Vereinbarung vor einiger Zeit hier - auch nur einmal. Es ist offenkundig, dass Dein Know-how deutlich zu gering ist, um einen Server im Internet zu betreiben. Du solltest wirklich auf eine managed-Server-Variante ausweichen oder ggf. Webspace und TS3-Slots mieten. Dürfte vermutlich auf das gleich summa summarum hinauslaufen und Du bist eine Menge Stress los.
So nun aber zu den bisherigen Ausführungen ...
Wegen D-Dos Angriffe ist mir klar das wir uns kaum schützen können jedoch waren es Angriffe auf SSH (hat fail2ban erfolgreich geblockt) und sehr viele Sachen blockt im Moment von mod_security2 (sogar genau genommen enorm viel)
Also bringen tun sie mir schon mal was, bei DDos wäre es na klar fatal aber das ist halt dann so
)
Habe WBB 3.1.7 (aktuellste) und habe eigentlich nur xcache drauf und sonst kein PHP Beschleuniger drauf ausser das bei WBB von Standard aus dabei wäre. Wie kommst du auf APC?
Die Betonung in TerraX's Beitrag lag vermutlich auf "idR". Bei korrekt konfigurierten Systemen ist es einem Besucher gar nicht möglich so viele Requests an das System zu schicken dass es zusammenbricht.
Cloudflare wäre ein potentieller temporärer "Hotfix" für dein Problem, aber keine Lösung.
Von Deiner geposteten Moment-Aufnahme (Screenie top) sieht es mir aus, wie ein 0815-Clanserver. Die CPU scheint sich zu langweilen. Insofern ist die hohe Anzahl an Zugriffen verwunderlich.
Eine Idee wäre - vorausgesetzt Du setzt Web-Statistiken ein wie Webalizer oder AW-Stats - mal in die Web-Statistiken zu schauen, woher die Masse an anfragen kommt. Das Ergebnis ist manchmal überraschend. Sind das Zugriffe aus Russland, Südamerika oder China etc. pp. könnte man ganze IP-Adress-Bereiche per IP-Tables oder .htaccess sperren. Das ist aber eine fragile und eher temporäre Lösung.
Zu SSH: Fail2Ban ist nach meiner Meinung Snakeoil. Eine sichere SSH-Konfig (Begrenzung auf dezidierte non-root-User und public-key-auth-only) lässt Dich sicherer schlafen als ein Pflaster zur Bekämpfung der Symptome aka Fail2Ban.
mod_security ist nur sinnvoll nach eigener Erfahrung mit einem eigenen ganz individuell angepassten Regelwerk. Standard-Rules oder sonstige Muster-Rules einzusetzen, zieht die nur die Performance unter den Füßen weg.
Du setzt den Apache als mpm-prefork ein. D.h. für jeden Client wird ein eigenständiger Apache-Prozess geladen. Und genau erst dann greift auch mod_security. Das eigentliche Dilemma ist damit schon bereits entstanden. Der Speicher wird "vollgemacht"
und CPU-Zeit wird verbraucht. Dann wird der Request durch das Regelwerk bearbeitet (noch mehr CPU-Zeit und RAM) und dann im positiven Falle wird der Request erst durch den Apache verarbeitet. mod_security setzt man als "chirugisches Skalpell" ein, nicht als Breitband-Antibiotikum.
Zu den PHP-Beschleunigern:
Laut der von Dir geposteten Angabe (
https://serversupportforum.de/threads/vserver-f5-crash.50305/post-328857) läuft auch noch Ioncube. Wbb bringt, AFAIK, keinen PHP-Beschleuniger mit wie auch, ist ja selbst eine PHP-Anwendung.
Warum ich APC empfehle? Hmm, aus eigener persönlicher Erfahrung - lief bisher sehr problemlos und wird auch aktiv weiterentwickelt, AFAIK. XCache verfolgt aber das gleiche Ziel. Du kannst gern nach Performance-Tests googlen und Dir selbst ein Urteil bilden, was evtl. für Deinen Zweck besser ist.
So zu dem mySQL-Problem und dem was D4F zu meinen Ausführungen anmerkte:
Ich hatte aus persönlicher Erfahrung (Admin WC3CL) ein einziges Mal mit dem "F5-Problem" zu kämpfen. Das war der erste Spieltag einer neuen Ligasaison mit einem neuen Ligascript (was ich mit heißer Nadel gestrickt hatte). Die Situation war folgende:
Die Deadline für Eingabe der obligatorischen Lineups war auf 18:45 Uhr gesetzt. Bis zu diesem Zeitpunkt waren die Lineups verdeckt also für den Gegner nicht sichtbar. Exakt 18:45 Uhr + 1 Sekunde wurden die Lineups systemseitig für alle angezeigt.
Damals hatten wir noch über 100 Clans in der Liga und dementsprechend haben ca. 800 User zu diesem Zeitpunkt ständig F5 gehämmert, um zu erfahren, wer gegen wen antreten wird. Zu diesem Zeitpunkt hatten wir einen kleinen vServer mit ca. 512 MB RAM und zu allem Übel Apache auf mpm-prefork mit PHP als reine CGI-Anwendung. Es hat knapp 5 Minuten gedauert bis die Kiste in die Knie gegangen ist.
Für den darauf folgenden Spieltag ein Wochenende später hatte ich dann meine Hausaufgaben gemacht inkl. bessere Hardware bei Hetzner damals.
Ergo, das o.g. ist eine klassische F5-Situation. Die kann ich mir bei Dir nicht vorstellen. Wenn Du natürlich die max_clients hochsetzt, bedeutet das natürlich, dass aus der PHP-Script-Abarbeitung mehr Anfragen an die mySQL-DB gesendet und verarbeitet werden müssen. Evtl. hast Du das zu radikal nach oben gesetzt.
Wie auch immer und da sind wir wieder am Anfang. Woher kommen die Anfragen.
Last but not least - ich bevorzuge Apache im mpm-worker-Betrieb mit PHP als fastCGI. Auch dafür gibt es genügend gute Tutorials.
P.S.: Wenn wir präzise wüssten, um welche Domain es sich handelt, könnten wir uns das System und evtl. die Foren-Statistiken mal anschauen - von außen ohne was "kaputt zu machen".
