OVH Community, your new community space.

Bardzo wysokie obciążenie CPU przez system


Spacedust
08-03-2012, 14:55
Cytat Napisał tzb
kiedyś z tym walczyłem,
jaką masz wersję apache i PHP + jaki konfig - php-cli czy phpcgi?
u mnie problemem był bug w apache.
rozwiązaniem okazało się przejście na nowego apache.

segfaulty to bardzo indywidualne problemy i trzeba diagnozować niestety indywidualnie, pomocny może okazać się "strace"

lub złap kilka Coredumpów
Kod:
vi httpd.conf
CoreDumpDirectory /tmp/apache2-gdb-dump
mkdir -p /tmp/apache2-gdb-dump
i zerknij na jakich funkcjach się wywala, to da jakiś punkt wyjścia.
Już odpisałem wyżej, był problem po stronie memcache, bo po wyłączeniu memcache wszystko było ok. Mam Apache 2.2.22 + php-cgi, a wkrótce pewnie 2.4.1, ale za dużo wszystko naraz, aby w ciągu jednego dnia wdrożyć

tzb
08-03-2012, 09:11
Cytat Napisał Spacedust
Jak się tego pozbyć, bo w Google jest cała przyczyn:
kiedyś z tym walczyłem,
jaką masz wersję apache i PHP + jaki konfig - php-cli czy phpcgi?
u mnie problemem był bug w apache.
rozwiązaniem okazało się przejście na nowego apache.

segfaulty to bardzo indywidualne problemy i trzeba diagnozować niestety indywidualnie, pomocny może okazać się "strace"

lub złap kilka Coredumpów
Kod:
vi httpd.conf
CoreDumpDirectory /tmp/apache2-gdb-dump
mkdir -p /tmp/apache2-gdb-dump
i zerknij na jakich funkcjach się wywala, to da jakiś punkt wyjścia.

Spacedust
07-03-2012, 14:04
Miałem wersję 3.0.6, która jest niestabilna. Szybka zmiana na 2.2.6 i wszystko działa http://pecl.php.net/package/memcache

Spacedust
07-03-2012, 12:50
Cytat Napisał vikingpl
Dobrze, ale sama konfiguracja. CGI, FCGI, PHP-FPM. Ile spawnujesz procesów per user?
Problem leżał po stronie memcache. Po wyłączeniu wszystko jest ok. Muszę teraz zastanowić się czemu to nie chce działać, a działało ładnie z lighttpd.

vikingpl
07-03-2012, 11:55
Dobrze, ale sama konfiguracja. CGI, FCGI, PHP-FPM. Ile spawnujesz procesów per user?

Spacedust
07-03-2012, 11:20
Cytat Napisał vikingpl
A jak konfigurowałeś PHP dla Lighty?
Z repo atomiccorp:

rpm -qi php
Name : php Relocations: (not relocatable)
Version : 5.3.10 Vendor: (none)
Release : 5.el5.art Build Date: pią 03 lut 2012 14:24:55 CET
Install Date: nie 19 lut 2012 19:02:58 CET Build Host: archelon
Group : Development/Languages Source RPM: php-5.3.10-5.el5.art.src.rpm
Size : 7847989 License: PHP
Signature : DSA/SHA1, pią 03 lut 2012 14:26:05 CET, Key ID 32a951145ebd2744
URL : http://www.php.net/
Summary : Osadzany w HTML-u język skryptowy PHP (PHP: preprocesor hipertekstu).
Description :
PHP is an HTML-embedded scripting language. PHP attempts to make it
easy for developers to write dynamically generated webpages. PHP also
offers built-in database integration for several commercial and
non-commercial database management systems, so writing a
database-enabled webpage with PHP is fairly simple. The most common
use of PHP coding is probably as a replacement for CGI scripts.

The php package contains the module which adds support for the PHP
language to Apache HTTP Server.

vikingpl
07-03-2012, 11:12
A jak konfigurowałeś PHP dla Lighty?

no4b
07-03-2012, 09:39
Musiałbyś debugować. GDB albo strace.

Spacedust
07-03-2012, 09:34
Jak się tego pozbyć, bo w Google jest cała przyczyn:

tail -f error_log
[Wed Mar 07 10:32:41 2012] [notice] child pid 12623 exit signal Segmentation fault (11)
[Wed Mar 07 10:32:43 2012] [notice] child pid 12213 exit signal Segmentation fault (11)
[Wed Mar 07 10:32:45 2012] [notice] child pid 11540 exit signal Segmentation fault (11)
[Wed Mar 07 10:32:46 2012] [notice] child pid 13250 exit signal Segmentation fault (11)
zend_mm_heap corrupted
[Wed Mar 07 10:32:51 2012] [notice] child pid 13173 exit signal Segmentation fault (11)
[Wed Mar 07 10:32:51 2012] [notice] child pid 13260 exit signal Segmentation fault (11)
zend_mm_heap corrupted
zend_mm_heap corrupted
[Wed Mar 07 10:33:06 2012] [notice] child pid 13950 exit signal Segmentation fault (11)
zend_mm_heap corrupted

Spacedust
06-03-2012, 23:24
Przestawiłem cały serwer na Apache 2.2.22 + mod_ruid2 i jest ogromna różnica we wydajności, ale ucina mi niektóre strony i trzeba je odświeżać.

Spacedust
06-03-2012, 22:11
Sprawdziłem to na przykładzie ApacheBench do prostej strony phpinfo:

Varnish + Lighttpd: Requests per second: 4.53 [#/sec] (mean) ???
Lighttpd: Requests per second: 4.71 [#/sec] (mean)
Apache: Requests per second: 229.80 [#/sec] (mean)
No to coś tutaj jest nie tak...

Spacedust
06-03-2012, 22:06
Cytat Napisał Flesh_
Jak reaguje na takie obciążenie ligttpd? Odrzuca połączenia?

Sprawdź jeszcze ten parametr może mieć wpływ na zdech systemu.
server.max-fds = 10000 jest to dość sporo (ale to zależy od charakterystyki serwisu) i jak on się ma do tego co jest w
cat /proc/sys/fs/file-max

Lightty zużywa zdaje się 3 desktyptory plików jeden fastCGI socket,drugi obsługa pliku do którego jest żądanie, 3 jakiś socket związany z połączeniem klient IP (nie pamiętam dokładnie).
Słuszna uwaga, kiedyś miałem nawet 20000, zmniejszę do 5000.

Odpaliłem sobie też Apache już z VirtualHostami na porcie 81 i chciałbym docelowo na niego przejść. Wszystko ładnie działa na porcie 81, ale na porcie 80 chciałem umieścić Varnisha tak jak to miałem z Lighttpd.

Jednak po zmianie w konfiguracji z backendu z Lighttpd na backend z Apache otrzymuję testową stronę Apache2. Czemu tak się dzieje ?

Flesh_
06-03-2012, 21:44
Jak reaguje na takie obciążenie ligttpd? Odrzuca połączenia?

Sprawdź jeszcze ten parametr może mieć wpływ na zdech systemu.
server.max-fds = 10000 jest to dość sporo (ale to zależy od charakterystyki serwisu) i jak on się ma do tego co jest w
cat /proc/sys/fs/file-max

Lightty zużywa zdaje się 3 desktyptory plików jeden fastCGI socket,drugi obsługa pliku do którego jest żądanie, 3 jakiś socket związany z połączeniem klient IP (nie pamiętam dokładnie).

Spacedust
06-03-2012, 21:09
Cytat Napisał victor
58.2%sy - oprogramowania z błędami takie rzeczy wywołują. Mysql sam w sobie miał bugów tak objawiających się dziesiątki. restart oprogramowania albo reboot duh
Restart już robiłem wielokrotnie, pomaga na chwilę i potem znowu to samo.

Sprawdziłem wszystkie możliwe wersje lighttpd 1.4.27/28/29/30/31-devel i na każdej tak się dzieje.

Aktualnie z wyłączonym cronem, zombie nie ma, a load od systemu nadal jest i strony się ładują ogólnie bardzo wolno jak na taki sprzęt:

top - 22:07:35 up 2:49, 1 user, load average: 7.49, 9.21, 9.59
Tasks: 342 total, 8 running, 334 sleeping, 0 stopped, 0 zombie
Cpu(s): 31.7%us, 47.1%sy, 0.0%ni, 18.9%id, 1.8%wa, 0.1%hi, 0.5%si, 0.0%st
Mem: 16371016k total, 16134704k used, 236312k free, 628204k buffers
Swap: 8388600k total, 1224k used, 8387376k free, 6462148k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2789 apache 25 0 340m 151m 1424 S 81.8 1.0 13:50.23 lighttpd
2787 apache 17 0 340m 153m 1428 S 65.8 1.0 13:30.79 lighttpd
2788 apache 17 0 340m 157m 1420 S 65.2 1.0 13:50.15 lighttpd
4347 mysql 15 0 5276m 2.6g 6084 S 39.9 16.8 47:28.04 mysqld
9292 greg-98 25 0 356m 26m 12m R 14.6 0.2 0:00.44 php-cgi
9293 marcinek 19 0 351m 21m 11m R 10.0 0.1 0:00.30 php-cgi
9291 admin 17 0 360m 30m 12m R 9.6 0.2 0:00.29 php-cgi
9295 lelunia 25 0 337m 16m 10m R 9.3 0.1 0:00.28 php-cgi
9294 admin 20 0 356m 26m 12m R 7.6 0.2 0:00.23 php-cgi
4624 varnish 18 0 12.3g 404m 81m S 2.7 2.5 3:27.78 varnishd
9306 apache 25 0 8 4 0 R 2.3 0.0 0:00.07 lighttpd
9308 apache 19 0 8 4 0 R 1.3 0.0 0:00.04 lighttpd
498 root 15 0 0 0 0 S 0.7 0.0 0:50.14 pdflush
3535 named 23 0 348m 70m 2596 S 0.3 0.4 2:09.49 named
5679 memcache 15 0 289m 160m 408 S 0.3 1.0 0:28.16 memcached
8338 root 15 0 12992 1328 820 R 0.3 0.0 0:00.40 top

victor
06-03-2012, 20:51
58.2%sy - oprogramowania z błędami takie rzeczy wywołują. Mysql sam w sobie miał bugów tak objawiających się dziesiątki. restart oprogramowania albo reboot duh

Spacedust
06-03-2012, 20:38
Cytat Napisał Flesh_
Na pierwszy ogień:
1) mysql - ewidentnie nie obija się
4347 mysql 15 0 4489m 1.7g 5860 S 93.7 10.6 20:49.26 mysqld

[mysqld]
#skip-networking
#bind-address = 0.0.0.0
#server-id=1
#log-bin = mysql-bin
#skip-name-resolve
#skip-grant-tables
datadir=/var/lib/mysql
tmpdir=/dev/shm
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
#skip-federated
old_passwords=1
skip-external-locking
query_cache_limit=64M
query_cache_size=128M
query_cache_type=1
max_connections=350
max_user_connections=50
max_connect_errors=100
#wait_timeout=600
thread_cache_size=8
key_buffer=2048M
innodb_buffer_pool_size = 128M
innodb_thread_concurrency = 16 # dwa razy procesory + dyski
innodb_log_file_size=64M
innodb_log_buffer_size = 16M
innodb_lock_wait_timeout = 100
innodb_flush_log_at_trx_commit = 2
innodb_support_xa=0
innodb_additional_mem_pool_size = 32M
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_max_dirty_pages_pct = 90
innodb_file_per_table
innodb_use_native_aio=0
sync_binlog=0
join_buffer=2M
max_allowed_packet=16M
table_open_cache=1024
table_cache=32k
sort_buffer_size=1M
read_buffer_size=1M
read_rnd_buffer_size=2M
max_connect_errors=100
tmp_table_size=512M
max_heap_table_size=512M
long_query_time=2
thread_concurrency=8
myisam_sort_buffer_size=64M
max_write_lock_count = 1
default-storage-engine=MyISAM

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

plugin-load=archive=ha_archive.so;blackhole=ha_blackhole. so

[mysqldump]
quick
max_allowed_packet=16M
2) masa procesów ze znacznikiem nie są to działające wątki, 69 zombie procesów. Prawdziwy wysyp żywych trupów.

Szczerze nie sugerowałbym się bindem, a przeczyścił to co wisi w systemie.
Restart demona mysql i coś z tym php-cgi wiszącym zrobiłbym.
1) Owszem, ale działa na SSD i tutaj nie ma problemów z wydajnością, zwłaszcza, że sporo danych leci prosto z varnisha + memcache.
2) php-cgi ładowane z modułami:

php-cgi -v
PHP 5.3.10 (cgi-fcgi) (built: Feb 3 2012 08:19:16)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v1.3.2, Copyright (c) 2005-2011, by mOo
with the ionCube PHP Loader v4.0.12, Copyright (c) 2002-2011, by ionCube Ltd., and
with TrueBug PHP Loader v1.2.0, Copyright (c) 2006-2010, by TrueBug Software
with SourceGuardian v8.2, Copyright (c) 2000-2010, by Inovica Ltd.
with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
Nie podoba mi się za to samo lighttpd i myślę, że to nim jest problem:

server.max-worker = 3
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"
server.max-connections = 1000
server.stat-cache-engine = "simple"
server.max-fds = 10000
server.max-keep-alive-idle = 0
#server.max-keep-alive-requests = 0
server.max-read-idle = 10
server.max-write-idle = 30
server.max-request-size = 40960
server.follow-symlink="enable"

Flesh_
06-03-2012, 20:21
Na pierwszy ogień:
1) mysql - ewidentnie nie obija się
4347 mysql 15 0 4489m 1.7g 5860 S 93.7 10.6 20:49.26 mysqld

2) masa procesów ze znacznikiem nie są to działające wątki, 69 zombie procesów. Prawdziwy wysyp żywych trupów.

Szczerze nie sugerowałbym się bindem, a przeczyścił to co wisi w systemie.
Restart demona mysql i coś z tym php-cgi wiszącym zrobiłbym.

Spacedust
06-03-2012, 18:04
Co może być powodem, że z dnia na dzień nagle wzrosło mi obciążenie procesora przez procesy systemowe ? W efekcie ciągle mam 100% obciążenia CPU. Nawet wyłączenie crona nic nie pomaga.

Stało się tak po zmianie tinydns na bind. Niestety powrót do tinydns nic nie pomaga.



Kod:
top - 19:01:04 up  1:19,  4 users,  load average: 15.75, 13.76, 12.51
Tasks: 387 total,  15 running, 303 sleeping,   0 stopped,  69 zombie
Cpu(s): 40.0%us, 58.2%sy,  0.0%ni,  0.3%id,  0.4%wa,  0.1%hi,  0.8%si,  0.0%st
Mem:  16371016k total, 16231396k used,   139620k free,  1502892k buffers
Swap:  8388600k total,        0k used,  8388600k free,  8430204k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4347 mysql     15   0 4489m 1.7g 5860 S 93.7 10.6  20:49.26 mysqld
 6464 apache    25   0  347m 206m  936 R 61.0  1.3  31:28.61 lighttpd
 6462 apache    25   0  347m 195m  936 R 58.3  1.2  29:05.13 lighttpd
 6463 apache    25   0  347m 206m  980 R 57.9  1.3  30:00.73 lighttpd
16169 agona2    25   0 98.5m  19m 5236 R 30.3  0.1   0:00.77 php-cgi
16135 admin     25   0     0    0    0 Z 27.6  0.0   0:00.70 php-cgi 
16150 mario271  24   0     0    0    0 Z 27.6  0.0   0:00.70 php-cgi 
31764 root      18   0 1188m 1.1g 4632 R 26.8  7.4  26:47.32 lphp.exe
16146 magdusie  24   0  363m  31m  12m R 23.2  0.2   0:00.59 php-cgi
16171 spokozio  25   0     0    0    0 Z 23.2  0.0   0:00.59 php-cgi 
16086 dazir     21   0     0    0    0 Z 22.0  0.0   0:00.70 php-cgi 
16153 rafaltra  25   0     0    0    0 R 21.7  0.0   0:00.55 php-cgi
16121 wojadann  25   0     0    0    0 Z 20.5  0.0   0:00.52 php-cgi 
16085 monia_ma  18   0     0    0    0 Z 20.1  0.0   0:00.70 php-cgi 
16106 dazir     16   0  370m  39m  13m S 18.5  0.2   0:00.60 php-cgi
16070 spokozio  25   0     0    0    0 Z 18.1  0.0   0:00.57 php-cgi 
16068 besthurt  16   0     0    0    0 Z 17.3  0.0   0:00.84 php-cgi 
16181 admin     25   0  360m  30m  13m R 16.5  0.2   0:00.42 php-cgi
16199 dazir     25   0  361m  32m  12m S 16.1  0.2   0:00.41 php-cgi
16044 mojasilo  25   0     0    0    0 Z 14.6  0.0   0:00.69 php-cgi 
16152 fhu_sun  25   0  352m  22m  11m R 14.6  0.1   0:00.37 php-cgi
16071 admin     25   0     0    0    0 Z 13.4  0.0   0:00.82 php-cgi 
16039 zootechn  17   0     0    0    0 Z 11.8  0.0   0:00.89 php-cgi 
16080 fhu_sun  24   0     0    0    0 Z  8.7  0.0   0:00.59 php-cgi 
16074 fhu_sun  25   0     0    0    0 Z  7.9  0.0   0:00.46 php-cgi 
16056 eline2    22   0     0    0    0 Z  6.7  0.0   0:00.79 php-cgi 
15996 admin     17   0     0    0    0 Z  6.3  0.0   0:01.09 php-cgi 
16201 root      17   0 27676  13m 4140 S  4.7  0.1   0:00.12 php
16211 spokozio  25   0  151m 4772 3408 R  4.7  0.0   0:00.12 php-cgi
16053 smerfetk  15   0     0    0    0 Z  3.5  0.0   0:00.71 php-cgi 
16054 dazir     23   0     0    0    0 Z  3.1  0.0   0:00.77 php-cgi 
16213 apache    25   0     8    4    0 R  3.1  0.0   0:00.08 lighttpd
 7428 root      15   0 13016 1368  820 R  2.8  0.0   0:02.37 top
16016 admin     17   0     0    0    0 Z  2.0  0.0   0:00.86 php-cgi 
 4774 varnish   18   0 12.3g 380m  81m S  0.8  2.4   2:16.94 varnishd
 5908 memcache  15   0  143m  77m  404 S  0.8  0.5   0:13.70 memcached
 2179 root      10  -5     0    0    0 S  0.4  0.0   0:02.41 md2_raid1
 3535 named     24   0  340m  61m 2592 S  0.4  0.4   0:35.41 named
 4569 lxlabs    15   0 66468 7472 1484 S  0.4  0.0   0:03.89 kloxo.httpd
 7848 matiowip  15   0  116m 3300 2560 S  0.4  0.0   0:00.45 pure-ftpd
Kernel domyślny CentOS: 2.6.18-274.18.1.el5 #1 SMP Thu Feb 9 12:45:44 EST 2012 x86_64 x86_64 x86_64 GNU/Linux

System CentOS 5.7 64-bit.

Używam lighttpd 1.4.29 + php 5.3.10 + mysql 5.5.21