Beim Versenden eines Newsletters – nicht mit WordPress – hat der Server 100% CPU

Beim Versenden eines Newsletters (nicht mit WordPress, aber mit einem anderen externen Newsletter-Kampagnen-Tool) an 3.298 Empfänger haben wir ein einzigartiges Öffnen: 155 , der Server hat 100% CPU von zu vielen httpd-Instanzen und mysql.

Die dedizierte Maschine …
CentOS Linux 6.5
Linux 2.6.32-431.17.1.el6.x86_64 auf x86_64
Webmin-Version: 1.701
processoren: 4
Echtes Gedächtnis: 15,57 GB insgesamt
Virtueller Speicher: 4 GB insgesamt
Apache / 2.2.15 (Keep Alive On)
MySQL v.5.1.73-Protokoll
PHP v.5.3.3
APC v.3.1.13
APC Statistiken

WordPress 3.9.2 mit Bucket ( http://themeforest.net/item/bucket-a-digital-magazine-style-wordpress-theme/6107209 ) Child Theme.
databasegröße = 1,6 GB
wp_posts = 118999 (Zeilen)
wp_postmeta = 1656568 (Zeilen)

WordPress Plugins laufen
1. Zusätzliche Bildgrößen (zui)
2. Kontaktformular 7
3. Benutzerdefiniertes Benutzerprofilfoto
4. Disqus Kommentar System
5. Google Analytics für WordPress
6. Newsletter Pro
7. NextGEN Galerie von Photocrati
8. NextScripts: Auto-Poster für soziale Netzwerke
9. P3 (Plugin Performance Profiler)
10. PixCodes
11. PixTypes
12. Nachtitel Titel Scroll
13. UBM Premium
14. Vixy YouTube Einbetten
15. W3-Gesamtcache (APC aktiviert)
16. Wordfence Sicherheit
17. WP-Optimieren
18. Noch ein anderes Related Posts Plugin

von wp-config.php

/** Enable W3 Total Cache */ define('WP_CACHE', true); // Added by W3 Total Cache /** Enable W3 Total Cache */ define( 'AUTOMATIC_UPDATER_DISABLED', true ); define('DISABLE_WP_CRON', true); define( 'DISALLOW_FILE_EDIT', true ); define('WP_MEMORY_LIMIT', '256M'); define('WP_MAX_MEMORY_LIMIT', '512M'); 

Ergebnisse aus dem MySQLTuner-Skript

 MySQLTuner 1.3.0 - Major Hayden  Run with '--help' for additional options and output filtering [OK] Currently running supported MySQL version 5.1.73-log [OK] Operating on 64-bit architecture -------- Storage Engine Statistics ------------------------------------------- [--] Status: +CSV +InnoDB +MRG_MYISAM [--] Data in MyISAM tables: 442M (Tables: 25) [--] Data in InnoDB tables: 1G (Tables: 68) [!!] Total fragmented tables: 61 -------- Security Recommendations ------------------------------------------- [OK] All database users have passwords assigned -------- Performance Metrics ------------------------------------------------- [--] Up for: 5d 21h 7m 0s (35M q [70.046 qps], 379K conn, TX: 152B, RX: 7B) [--] Reads / Writes: 59% / 41% [--] Total buffers: 5.9G global + 4.2M per thread (500 max threads) [OK] Maximum possible memory usage: 8.0G (51% of installed RAM) [OK] Slow queries: 0% (23K/35M) [OK] Highest usage of available connections: 17% (88/500) [OK] Key buffer size / total MyISAM indexes: 128.0M/75.2M [OK] Key buffer hit rate: 99.8% (101M cached / 155K reads) [OK] Query cache efficiency: 46.9% (11M cached / 23M selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 1% (30K temp sorts / 1M sorts) [!!] Temporary tables created on disk: 32% (1M on disk / 4M total) [OK] Thread cache hit rate: 99% (259 created / 379K connections) [!!] Table cache hit rate: 0% (96 open / 64K opened) [OK] Open file limit used: 0% (2/65K) [OK] Table locks acquired immediately: 99% (21M immediate / 21M locks) [OK] InnoDB buffer pool / data size: 4.0G/1.0G [OK] InnoDB log waits: 0 -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance Temporary table size is already large - reduce result set size Reduce your SELECT DISTINCT queries without LIMIT clauses Increase table_cache gradually to avoid file descriptor limits Read this before increasing table_cache over 64: Variables to adjust: table_cache (> 64) 

Kann mir bitte jemand vorschlagen, wonach er suchen soll?
Vielen Dank!

Solutions Collecting From Web of "Beim Versenden eines Newsletters – nicht mit WordPress – hat der Server 100% CPU"

Ich nehme an, Sie haben zwei Probleme, und eines enthüllt einfach das andere.

Das erste Problem besteht darin, dass die Newsletter-Software / der Service wahrscheinlich eindeutige Links zum Verfolgen von Klicks und Kampagnen verwendet. Wenn beispielsweise das Google Analytics-Tracking in einer MailChimp-Kampagne aktiviert ist, wird eine utm_campaign Variable an jede Ziel-URL und eine eindeutige benutzerspezifische utm_term Variable utm_term .

Das bedeutet, dass jeder einzelne Klick in Ihrer E-Mail-Kampagne eine eindeutige URL ist und Ihr Seiten-Caching-Plugin es wahrscheinlich nicht aus dem Cache bereitstellt (vorausgesetzt, Sie verwenden ein Seiten-Caching-Plugin), sondern generieren es von Grund auf verursacht die Belastung. Ich bin mir nicht sicher über W3 Total Cache, es gibt wahrscheinlich eine Einstellung oder etwas, aber hier ist, wie ich utm_ Variablen in meiner Batcache Konfiguration ignoriere:

 // Ignore get keys not used by PHP to serve cached pages. $ignore_get_keys = array( 'utm_source', 'utm_medium', 'utm_term', 'utm_content', 'utm_campaign' ); parse_str( $_SERVER['QUERY_STRING'], $query ); foreach ( $ignore_get_keys as $key ) { if ( isset( $query[ $key ] ) ) unset( $query[ $key ] ); if ( isset( $_GET[ $key ] ) ) unset( $_GET[ $key ] ); } $_SERVER['QUERY_STRING'] = http_build_query( $query ); 

Das zweite Problem ist die Tatsache, dass Ihr 4-Core-16G-Server mit 155 öffnet. Ein ordnungsgemäß konfigurierter $ 5-Single-Core-512M-Server kann mehr als 5.000 Anfragen pro Sekunde verarbeiten, wobei das Seiten-Caching fair ist. Ungefähr 5-10 pro Sekunde ohne Caching.

Nach meinen groben Berechnungen sollten Sie in der Lage sein, mindestens 50 Anfragen pro Sekunde ohne Caching zu bedienen. Wenn 155 öffnet, verursacht das massive Lastprobleme auf Ihrem Server, dann ist etwas eindeutig falsch.

Profiling ist ein guter Anfang. Holen Sie sich ein XHProf-Modul und Sie können es sogar auf Ihrem Produktionsserver tun. Haben Sie E-Mail- und / oder Protokollanforderungen, die länger als 1 s dauern, werden Sie den Engpass wahrscheinlich schnell erkennen.

Nachdem Sie den Engpass erkannt und sortiert haben, empfehle ich Ihnen Apache zugunsten von nginx und php 5.6 im fpm-Modus.