Release candidate 1 eating up 100% CPU over time?

I am not afraid to tell you guys this, as you probably realize it. The release candidate is buggy as hell.. I have tried to isolate it with error reports, etc. but I have a big board and it has been killing the site over and over again. I do not blame you for this, as it was my call to install the release candidate. In this stage it must be considered a beta... there is a memory leak somewhere in the code that is destroying every server I place the site on. When VBSEO is disabled, it doesn't happen. I wish I could provide more information to you, and would even be willing to give you access to the site. The problem is that its a production environment and I can't have it keep going down. I have moved back to vanilla vBulletin 4. My users are pissed.

Hello,

We are not aware of this happening. We are running the same script here on vbseo.com and have not had problems. Are there any more details you can provide to help us narrow down what script is causing this? any other mods installed? the latest pl1? etc

Hi Brian,

I have no idea what is causing the problem - all I know is that the site can hit around 50 hits/second with apache. At that point, over time, maybe a few hours, the entire load average increases like crazy. It goes up to 60... then 100... then 200.. then 300... load average today went to 1000. This is on a VPS, CentOS 5.3 64-bit with dedicated CPANEL on an I7 Nehalem Processor. VPS with 6GB dedicated to the site.

I can tell you that the problem immediately goes away when VBSEO is turned off and all rewrite rules are disabled. The issue seems to be related to VBSEO. For awhile, I did not realize it was a processor consumption problem. I have also tested it under an i5 environment with the same results.

Bare in mind this was not happening at all with 3.5.x and the stable build of VBSEO. The load averages go through the roof. The problem was taking place prior to installing any additional plugins, so I believe it must be VBSEO. Load average now is .069, .40, .25, as opposed to 1000+ to the point that the server is about to go into kernel panic.

I am using the latest version, but did import the old data from VBSEO under 3.8.x. This makes me wonder if that has something to do with it, but I'm uncertain. Obviously resetting the unique URLs and everything is disadvantageous and not a good idea for this site, but right now no re-write rules are in effect.

I have taken the "atomic bomb" solution for my site of just re-directing all deadlinks back to the forum root, which is bad for SEO. This was an upgrade, as opposed to a complete clean install of VBSEO, so maybe that has something to do this. An upgrade that effected, no doubt, thousands of threads immediately following the upgrade to VB4.

Can you please supply us more details :

Phpinfo file link
Load levels with vBSEO turned off and enabled
Online user + guest count on your forum ( if server has more than one sites running please supply the count of all user + guest count )
Number of sites running on same server

For your information i am also using Nehalm I7 on my own dedicated and i don't face this issue. In fact my current load levels are 0.00 0.02 0.00 with 90 user + guest online .

Originally Posted by Mert Gökçeimam

Can you please supply us more details :

Phpinfo file link
Load levels with vBSEO turned off and enabled
Online user + guest count on your forum ( if server has more than one sites running please supply the count of all user + guest count )
Number of sites running on same server

For your information i am also using Nehalm I7 on my own dedicated and i don't face this issue. In fact my current load levels are 0.00 0.02 0.00 with 90 user + guest online .

PHPinfo: phpinfo()

Load levels after 24 hours with VBSEO on: load average: 1043.53, 1018.94, 953.72
Load levels after 24 hours with VBSEO off: load average: 0.46, 0.25, 0.21

iptables and tailwatchd off just in case this was causing a conflict.

One site. Number of users with 3600sec. timeout: average is 1200-2000 for a 24-hour of around 40-50K
One site on the entire server with multiple domains redirecting.

Can you please create a support ticket with ftp , admincp and vBSEO cp login information for investigation

Originally Posted by Mert Gökçeimam

Can you please supply us more details :

Phpinfo file link
Load levels with vBSEO turned off and enabled
Online user + guest count on your forum ( if server has more than one sites running please supply the count of all user + guest count )
Number of sites running on same server

For your information i am also using Nehalm I7 on my own dedicated and i don't face this issue. In fact my current load levels are 0.00 0.02 0.00 with 90 user + guest online .

I do not know if this will help

/usr/local/apache/conf/extra/httpd-mpm.conf:

Code:

<IfModule mpm_prefork_module>
    StartServers          30
    MinSpareServers       5
    MaxSpareServers      50
    ServerLimit         2000
    MaxClients          1800
    MaxRequestsPerChild   0
</IfModule>

/usr/local/lib/php.ini:

Code:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
max_execution_time = 30
max_input_time = 120
memory_limit = 128M
mysql.allow_persistent = On
mysql.trace_mode = Off

/etc/my.cnf

Code:

[mysqld]
safe-show-database
old-passwords = 1
max_connections =2048
max_user_connections = 1024
key_buffer_size = 2048M
myisam_sort_buffer_size = 64M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 2M
table_cache = 4000
thread_cache_size = 384
wait_timeout = 20
connect_timeout = 10
tmp_table_size = 2048M
max_heap_table_size = 512M
max_allowed_packet = 64M
net_buffer_length = 16384
max_connect_errors = 10
thread_concurrency = 16
concurrent_insert = 2
table_lock_wait_timeout = 30
read_rnd_buffer_size = 786432
bulk_insert_buffer_size = 8M
query_cache_limit = 7M
query_cache_size = 64M
query_cache_type = 1
query_prealloc_size = 262144
query_alloc_block_size = 65536
transaction_alloc_block_size = 8192
transaction_prealloc_size = 4096
max_write_lock_count = 16
long_query_time = 5
skip-name-resolve
skip-locking
 
[mysqld_safe]
open_files_limit = 8192
 
[mysqldump]
quick
max_allowed_packet = 16M
 
[myisamchk]
key_buffer = 384M
sort_buffer = 384M
read_buffer = 256M
write_buffer = 256M

Per your request, the ID for this incident is set as: 7513-QSVN-8488