PDA

View Full Version : Php.exe out of control


agrauch
Wed 23rd Nov '05, 6:52pm
I'm migrating from UBB to vBulletin 3.5.0 and we're having some issues with the server. I don't have a whole lot of information about the machine, I'm just a hired gun and haven't talked to the hosting company. I'll post more information as I get it. Here's what I know:

1. Shared Server (unknow number of sites)

2. 3GHz 1GB Ram
Windows 2000
IIS / cgi-fcgi
PHP 4.3.1
mySQL 3.23.52-max-debug

3. N/A

4. Unknown

5. Unknown

6.
back_log 50
basedir C:\mysql\
bdb_cache_size 8388572
bdb_log_buffer_size 32768
bdb_home C:\mysql\data\
bdb_max_lock 10000
bdb_logdir
bdb_shared_data OFF
bdb_tmpdir C:\WINNT\TEMP\
bdb_version Sleepycat Software: Berkeley DB 3.2.9a: (August 12, 2002) binlog_cache_size 32768
character_set latin1
character_sets latin1 big5 czech euc_kr gb2312 gbk sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5 concurrent_insert ON
connect_timeout 5
datadir C:\mysql\data\
delay_key_write ON
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
flush OFF
flush_time 1800
have_bdb YES
have_gemini NO
have_innodb DISABLED
have_isam YES
have_raid NO
have_openssl NO
init_file
innodb_additional_mem_pool_size 1048576
innodb_buffer_pool_size 8388608
innodb_data_file_path
innodb_data_home_dir
innodb_file_io_threads 4
innodb_force_recovery 0
innodb_thread_concurrency 8
innodb_flush_log_at_trx_commit 0
innodb_fast_shutdown ON
innodb_flush_method
innodb_lock_wait_timeout 50
innodb_log_arch_dir
innodb_log_archive OFF
innodb_log_buffer_size 1048576
innodb_log_file_size 5242880
innodb_log_files_in_group 2
innodb_log_group_home_dir
innodb_mirrored_log_groups 1
interactive_timeout 28800
join_buffer_size 131072
key_buffer_size 8388572
language C:\mysql\share\english\
large_files_support ON
log OFF
log_update OFF
log_bin OFF
log_slave_updates OFF
log_long_queries OFF
long_query_time 10
low_priority_updates OFF
lower_case_table_names 1
max_allowed_packet 1048576
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connections 200
max_connect_errors 30
max_delayed_threads 20
max_heap_table_size 16777216
max_join_size 4294967295
max_sort_length 1024
max_user_connections 20
max_tmp_tables 32
max_write_lock_count 4294967295
myisam_max_extra_sort_file_size 256
myisam_max_sort_file_size 2047
myisam_recover_options 0
myisam_sort_buffer_size 8388608
net_buffer_length 16384
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
open_files_limit 0
pid_file C:\mysql\data\db2.pid
port 3306
protocol_version 10
record_buffer 131072
record_rnd_buffer 131072
query_buffer_size 0
safe_show_database OFF
server_id 0
slave_net_timeout 3600
skip_locking ON
skip_networking OFF
skip_show_database OFF
slow_launch_time 2
socket MySQL
sort_buffer 2097116
sql_mode 0
table_cache 64
table_type MYISAM
thread_cache_size 0
thread_stack 65536
transaction_isolation READ-COMMITTED
timezone Eastern Standard Time
tmp_table_size 33554432
tmpdir C:\WINNT\TEMP\
version 3.23.52-max-debug
wait_timeout 900


7.
Aborted_clients 3532
Aborted_connects 6351
Bytes_received 0
Bytes_sent 0
Com_admin_commands 13327
Com_alter_table 333
Com_analyze 6
Com_backup_table 0
Com_begin 58
Com_change_db 749881
Com_change_master 0
Com_check 0
Com_commit 127
Com_create_db 15
Com_create_function 0
Com_create_index 85
Com_create_table 447
Com_delete 131008
Com_drop_db 5
Com_drop_function 0
Com_drop_index 0
Com_drop_table 311
Com_flush 22
Com_grant 14
Com_insert 342985
Com_insert_select 2410
Com_kill 0
Com_load 5
Com_load_master_table 0
Com_lock_tables 10
Com_optimize 10
Com_purge 0
Com_rename_table 0
Com_repair 0
Com_replace 69281
Com_replace_select 0
Com_reset 0
Com_restore_table 0
Com_revoke 0
Com_rollback 0
Com_select 5921504
Com_set_option 974
Com_show_binlogs 143
Com_show_create 469
Com_show_databases 865
Com_show_fields 4596
Com_show_grants 4
Com_show_keys 1766
Com_show_logs 0
Com_show_master_status 0
Com_show_open_tables 0
Com_show_processlist 85
Com_show_slave_status 0
Com_show_status 42
Com_show_innodb_status 0
Com_show_tables 12737
Com_show_variables 1444
Com_slave_start 0
Com_slave_stop 0
Com_truncate 9
Com_unlock_tables 10
Com_update 620449
Connections 433067
Created_tmp_disk_tables 53203
Created_tmp_tables 155122
Created_tmp_files 16
Delayed_insert_threads 0
Delayed_writes 0
Delayed_errors 0
Flush_commands 1
Handler_delete 162600
Handler_read_first 2170108
Handler_read_key 129739696
Handler_read_next 336477499
Handler_read_prev 171299370
Handler_read_rnd 201344594
Handler_read_rnd_next 2221846558
Handler_update 4716379
Handler_write 5440245
Key_blocks_used 7764
Key_read_requests 395621308
Key_reads 3051995
Key_write_requests 2037667
Key_writes 1313131
Max_used_connections 37
Not_flushed_key_blocks 0
Not_flushed_delayed_rows 0
Open_tables 64
Open_files 119
Open_streams 0
Opened_tables 683026
Questions 8290906
Select_full_join 96038
Select_full_range_join 8356
Select_range 497748
Select_range_check 10
Select_scan 2691830
Slave_running OFF
Slave_open_temp_tables 0
Slow_launch_threads 6
Slow_queries 20
Sort_merge_passes 8
Sort_range 246917
Sort_rows 219705585
Sort_scan 800338
Table_locks_immediate 10220150
Table_locks_waited 1456
Threads_cached 0
Threads_created 433066
Threads_connected 12
Threads_running 1
Uptime 923253

8. Unknown, but given that it's a shared server I'm guessing that vB is not alone.

9. At the moment there are usually only 1 or 2 users on at a given time, we're testing the move.

10. http://www.backcountryworld.com/phpinfo.php

11. N/A

12. vB 3.5.0

The problem is that when a user requests to view a thread, a newly started php.exe process uses about 25% of the CPU and apparently doesn't stop for a while. Since the process doesn't go away quickly, the CPU is quickly at 100% usage and the web host starts to complain.

Given that this is a shared server, it seems unlikely that I can change the PHP or mySQL installations. Is there any thing I can do with vB to help quite down the server?

Any body have any bright ideas?

Cheers

Scott MacVicar
Wed 23rd Nov '05, 7:18pm
Dont run PHP as a CGI, there is an overhead of starting up the PHP engine every time. Run PHP as an ISAPI module (something the host will need to do) and install APC http://pecl4win.php.net

Most hosts should be quite willing to do this as it will benefit everyone on the server.

agrauch
Wed 23rd Nov '05, 9:09pm
I was thinking that running PHP as an ISAPI module would be part of the solution. I'm not sure if the host will agree, though it sounds like a reasonable request. Switching hosts is another option.

Is there no way for vB to run well on a shared server with PHP running as a CGI?

Scott MacVicar
Wed 23rd Nov '05, 9:25pm
Its not vBulletin but any sort of server script runs bad as a CGI as it requires the creation of that external process and then the startup of the engine. Most hosts run it as a FastCGI or a ISAPI handler by default.