apache is faster ?

#1
Hello

i am using lsws for about 3 months , and it was good
one of my server in the last three days start to be very slow
i mean loading web pgaes started to be very slow
the server load is
0.54 (8 cpus)
Memory usage
10 %

when i switch to apache the pages start to load just fine
but when i get back to lsws the page takes about 20 - 30 seconds to load

i have not changed anything in the server
and i dont know from where this issue came

i tried re-installing lsws again and builded matching php binary
but that didnt help


i am using lsws as cpanel plug-in , if this helps


anyone can help me befor get back to Apache + MPM Worker ?
 

NiteWave

Administrator
#2
need more detail info to identify the problem. for example disk usage, is /tmp nearly full? any error message in error.log and stderr.log? etc
 
#3
ok here are some of the info

Code:
root@de [/tmp/ubru]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             1.4T  139G  1.2T  11% /
none                  5.9G     0  5.9G   0% /dev/shm
/usr/tmpDSK           485M   24M  437M   6% /tmp
error.log file are 0 bytes in lsws

Code:
root@de [/usr/local/lsws/admin/logs]# ls -al
total 8
drwxr-xr-x 2 root   root  4096 Apr 18 17:57 ./
drwxr-xr-x 9 root   root  4096 Apr 18 17:51 ../
-rw-r--r-- 1 nobody lsadm    0 Apr 18 17:57 access.log
-rw-r--r-- 1 nobody lsadm    0 Apr 18 17:57 error.log
some of stderr.log
Code:
2010-02-04 05:39:30.603 [STDERR] [30319] EACCELERATOR: PHP crashed on opline 23 of explode() at /home/xxxx/public_html/tempsystem.php:11
2010-02-11 16:25:00.276 [STDERR] *** glibc detected *** lsphp5: free(): invalid next size (fast): 0x0000000000d49ac0 ***
2010-02-11 16:25:00.282 [STDERR] *** glibc detected *** lsphp5: free(): invalid next size (fast): 0x0000000000d49ac0 ***
2010-02-11 16:25:00.322 [STDERR] ======= Backtrace: =========
2010-02-11 16:25:00.322 [STDERR] /lib64/libc.so.6[0x38f22722ef]
2010-02-11 16:25:00.322 [STDERR] /lib64/libc.so.6(cfree+0x4b)[0x38f227273b]
2010-02-11 16:25:00.322 [STDERR] /lib64/libcrypto.so.6(CRYPTO_free+0x1d)[0x38f4adae9d]
2010-02-11 16:25:00.322 [STDERR] /lib64/libcrypto.so.6(OBJ_NAME_remove+0x51)[0x38f4a5c391]
2010-02-11 16:25:00.322 [STDERR] /lib64/libcrypto.so.6[0x38f4a7e588]
2010-02-11 16:25:00.322 [STDERR] /lib64/libcrypto.so.6(OBJ_NAME_cleanup+0x3a)[0x38f4a5c1ca]
2010-02-11 16:25:00.322 [STDERR] /lib64/libcrypto.so.6(EVP_cleanup+0x18)[0x38f4a82288]
2010-02-11 16:25:00.322 [STDERR] /opt/curlssl/lib/libcurl.so.4(Curl_ossl_cleanup+0xe)[0x7fb2dad8408e]
2010-02-11 16:25:00.322 [STDERR] /opt/curlssl/lib/libcurl.so.4(Curl_ssl_cleanup+0x12)[0x7fb2dad94c52]
2010-02-11 16:25:00.322 [STDERR] /opt/curlssl/lib/libcurl.so.4(curl_global_cleanup+0x43)[0x7fb2dad8c7a3]
2010-02-11 16:25:00.322 [STDERR] lsphp5(zm_shutdown_curl+0x9)[0x4b2b29]
2010-02-11 16:25:00.322 [STDERR] lsphp5(module_destructor+0x31)[0x657d71]
2010-02-11 16:25:00.322 [STDERR] lsphp5[0x65e5b2]
2010-02-11 16:25:00.322 [STDERR] lsphp5(zend_hash_graceful_reverse_destroy+0x18)[0x65e828]
2010-02-11 16:25:00.322 [STDERR] ======= Backtrace: =========
2010-02-11 16:25:00.322 [STDERR] lsphp5(zend_shutdown+0x27)[0x654097]
2010-02-11 16:25:00.322 [STDERR] /lib64/libc.so.6[0x38f22722ef]
2010-02-11 16:25:00.322 [STDERR] /lib64/libc.so.6(cfree+0x4b)[0x38f227273b]
2010-02-11 16:25:00.322 [STDERR] /lib64/libcrypto.so.6(CRYPTO_free+0x1d)[0x38f4adae9d]
2010-02-11 16:25:00.322 [STDERR] lsphp5(php_module_shutdown+0x2a)[0x61120a]
2010-02-11 16:25:00.322 [STDERR] /lib64/libcrypto.so.6(OBJ_NAME_remove+0x51)[0x38f4a5c391]
2010-02-11 16:25:00.323 [STDERR] /lib64/libcrypto.so.6[0x38f4a7e588]
2010-02-11 16:25:00.323 [STDERR] /lib64/libcrypto.so.6(OBJ_NAME_cleanup+0x3a)[0x38f4a5c1ca]
2010-02-11 16:25:00.323 [STDERR] lsphp5(main+0x174)[0x6d73c4]
2010-02-11 16:25:00.323 [STDERR] /lib64/libcrypto.so.6(EVP_cleanup+0x18)[0x38f4a82288]
2010-02-11 16:25:00.323 [STDERR] /opt/curlssl/lib/libcurl.so.4(Curl_ossl_cleanup+0xe)[0x7fb2dad8408e]
2010-02-11 16:25:00.323 [STDERR] /opt/curlssl/lib/libcurl.so.4(Curl_ssl_cleanup+0x12)[0x7fb2dad94c52]
2010-03-15 08:34:24.596 [STDERR] *** glibc detected *** lsphp5: corrupted double-linked list: 0x0000000000f594d0 ***
2010-03-15 08:34:24.671 [STDERR] ======= Backtrace: =========
2010-03-15 08:34:24.671 [STDERR] /lib64/libc.so.6[0x38f22723e5]
2010-03-15 08:34:24.671 [STDERR] /lib64/libc.so.6(cfree+0x4b)[0x38f227273b]
2010-03-15 08:34:24.671 [STDERR] lsphp5(zend_hash_destroy+0x50)[0x65e8e0]
2010-03-15 08:34:24.672 [STDERR] lsphp5(destroy_zend_class+0xc9)[0x64af69]
2010-03-15 08:34:24.672 [STDERR] lsphp5(zend_hash_destroy+0x38)[0x65e8c8]
2010-03-15 08:34:24.672 [STDERR] lsphp5(zend_shutdown+0x46)[0x6540b6]
2010-03-15 08:34:24.672 [STDERR] lsphp5(php_module_shutdown+0x2a)[0x61120a]
2010-03-15 08:34:24.672 [STDERR] lsphp5(main+0x174)[0x6d73c4]
2010-03-15 08:34:24.672 [STDERR] /lib64/libc.so.6(__libc_start_main+0xf4)[0x38f221d994]
2010-03-15 08:34:24.672 [STDERR] lsphp5[0x463de9]
2010-03-15 08:34:24.672 [STDERR] ======= Memory map: ========
2010-03-15 08:34:24.672 [STDERR] 00400000-00a40000 r-xp 00000000 08:01 29279293                           /usr/local/lsws/fcgi-bin/lsphp-5.2.12
 

NiteWave

Administrator
#4
looks like lsphp5 crash is the reason of slowness?

you may need rebuild php.

please check /opt/curlssl/lib/libcurl.so.4 is 32-bit or 64-bit. not sure if it's a problem to mix 32-bit and 64-bit library together.

also for:
Code:
/usr/tmpDSK           485M   24M  437M   6% /tmp
we have experienced some people use NFS as /tmp, and made lsws very slow. As a quick check, just "ls -R /tmp" to see if it's normal.

Code:
root@de [/usr/local/lsws/admin/logs]# ls -al
this is lsws web admin console log, should check /usr/local/lsws/logs
 
Top