100% CPU usage with vBSEO

Summary: Two vBulletin web hosting forums running as virtual hosts in a VPS environment on high-performance hardware. Noted drastic change in CPU load most requests on vBSEO forum after installing vBSEO (performance on other forum has not changed).


Environment:

• Virtualization: OpenVZ
• CPU: Sharing burstable CPU time on 2 quad-core Intel Xeon 1.60GHz processors
• RAM: 1024 MB (~260 MB used while idling)
• Disk: 40 GB (849 MB used)
• OS: CentOS 5.2
• Apache: 2.2.3
• PHP: 5.1.6
• Zend Engine: 2.1.0
• XCache: 1.2.2

Sites:

Both virtual hosts are relatively low-traffic (<2000 visits/day) and neither had any performance issues prior to the installation of vBSEO.

• forums.spry.com - vBulletin 3.7.2 PL 1 - vBSEO not installed, performance
• forums.vpslink.com - vBulletin 3.7.2 PL 1 - vBSEO 3.2.0 installed

Full description of the issue:

Use of this plug-in has consistently caused Apache processes to consume inordinate CPU time (generally reaches 100% for the duration of requests served by vBSEO).

Depending upon the page which is requested, load times average between a minimum of 9 seconds (index) to 18 seconds (subforum index). Subforum pages which display many links demonstrate the worst performance.

I believe that this issue may be related to the lack of caching a threadid => CRU name lookup. I really would not care if it takes up a few MB of memory, have plenty to go around.

CPU time comes at a premium and 100% CPU load on a core for 10-20 seconds per page request is unacceptable for the user experience and system stability.


Action taken:

1) Installed vBSEO at forums.vpslink.com, enabled rewrite rules and added directives to httpd.conf

2) Noted performance issues immediately, no corroborating Apache or PHP errors

3) Installed and configured XCache (see configuration below)


XCache Configuration:

Code:

xcache.shm_scheme = "mmap"
xcache.size = 64M
xcache.count = 1
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 0
xcache.var_size = 16M
xcache.var_count = 4
xcache.var_slots = 8K
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.var_gc_interval = 300
xcache.test = Off
xcache.readonly_protection = Off
xcache.mmap_path = "/tmp/xcache"
xcache.coredump_directory = ""
xcache.cacher = On
xcache.stat = On
xcache.optimizer = Off
xcache.coverager = Off
xcache.coveragedump_directory = ""

Any suggestions appreciated - I would prefer not to escalate this issue to our systems administrators for further troubleshooting, as it appears to be isolated to the use of vBSEO on the forums.vpslink.com virtual host and is not evident on the forums.spry.com virtual host.

i've had nothing but problems with xcache on my box.
Xcache: Server, ssh, putty...: SkeyMedia

I currently run eAccelerator with good results.

otherwise, have a look through these:
vBSEO Optimization Tips

Perhaps it's xcache actually running up your usage?
Have you tried any other PHP accelerators?

Originally Posted by EGS

Perhaps it's xcache actually running up your usage?
Have you tried any other PHP accelerators?

Caching systems were installed after noting CPU load issues while running vBSEO (Action taken: #2 > #3).

I'd expect a series of preg_replace() calls to bog things down a bit, and I was surprised that vBSEO did not include a threadid => CRU lookup array or a series of constant definitions.

Have also tried memcached with identical results.

please post your my.cnf file

Originally Posted by briansol

please post your my.cnf file

The MySQL databases are hosted on a separate server and no directives are specified for the MySQL client in the my.cnf for the VPS which is hosting our forums.

my.cnf Directives (from DB server)

Code:

[mysqld]
port            = 3306
socket          = /tmp/mysql.sock
skip-locking
max_allowed_packet = 4M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M

key_buffer = 1024M
max_connections=400

log-bin=/var/log/mysql/binlog
binlog-ignore-db=test,sbtest

relay-log=/var/log/mysql/relay-bin

relay-log-space-limit=5G

server-id                      = 10
replicate-same-server-id       = 0
auto_increment_increment       = 10
auto_increment_offset          = 1
log-slave-updates

innodb_data_home_dir = /var/db/mysql/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/db/mysql/
innodb_log_arch_dir = /var/db/mysql/

innodb_buffer_pool_size = 1024M
innodb_additional_mem_pool_size = 8M

innodb_log_file_size = 128M
innodb_log_buffer_size = 4M
innodb_flush_log_at_trx_commit = 2

The forum w/o vBSEO has no issues with database connectivity, and the administrative interface for the forum with vBSEO is similarly snappy, database server performance does not seem to be related.

that all looks ok.

i guess the thing to suggest at this point is to upgrade apache and php

• Apache: 2.2.3
• PHP: 5.1.6

2.2.9 is out for apache as is 5.2.6 of php. Frankly, the 5.1 series of php sucked. you should upgrade that asap

Solution received from vBSEO support:

Changed Limit URL Length (was set to 255) to 0 - immediate drop in CPU load, application now performs exactly as expected.

Originally Posted by danlefree

Solution received from vBSEO support:

Changed Limit URL Length (was set to 255) to 0 - immediate drop in CPU load, application now performs exactly as expected.

Sorry just to clarify. Setting Limit URL Length from 255 to 0 will improve performance?

Thanks

Hello Hayden ,

Limit url lenght option is defined to use with max 6-7 words. When it is set to 255 , it may cause issues. Suggested setting is maximum 6-7 words.

thanks. Mine was set to 0. Changes it to 5.

As per stopword removal. Smart would be the better* setting for this instead of yes as far as server performance is concerned correct?

No being the best performance setting?

0 (or off) is the best performance setting. any figure you put in there will require processing cycles to figure out the length and to trim it appropriately.