Форум сетевых администраторов (http://netadmin.ws/forum/index.php)
- VBulletin 2.x.x (http://netadmin.ws/forum/forumdisplay.php?forumid=45)
-- Производительность/Speed Up/Тюниниг vb/PHP/mySQL/Apache (http://netadmin.ws/forum/showthread.php?threadid=3729)

Производительность/Speed Up/Тюниниг vb/PHP/mySQL/Apache

Использую vb уже более года. В один момент при глобальном обновлении сервера и софта (freebsd/vb/php/ports etc/) обнаружил заметное снижени производительности vb. Тормоза при загрузге главной страницы и форумов. Причем выглядят как задержки резолва или вэйты в программе, ибо сервак по стату top не шибко в это время и занят. Что может быть причиной? vb 2.2.6. На перегруженность хаками не жалуюсь, да и железо не ацтой. Другие задачи выполняются лихо, другие php также. Хочу спросить кто знает какие hits/trips по тюнингу php mysql vb apache. Пока я не выкладываю, то что сделано у меня, т.к. результатов от них не вижу.

Bochkarev_D.S. добавил 19-12-2002 в 05:08:35:
По freebsd можно не писать, там все отлизано почти.

с нуля не пробовал рядом поставить с полупустой базой, без хаков и сравнить ?

вот такой стат средний, есть мысли по повышению производительности?

Http processes currently running = 68
Mysql processes currently running = 4

Netstat information summary
1 LAST_ACK
2 SYN_SENT
5 FIN_WAIT_2
10 LISTEN
17 TIME_WAIT
24 ESTABLISHED

+--------------------------+-----------+
| Variable_name | Value |
+--------------------------+-----------+
| Aborted_clients | 31 |
| Aborted_connects | 0 |
| Bytes_received | 12378327 |
| Bytes_sent | 161653318 |
| Com_admin_commands | 0 |
| Com_alter_table | 0 |
| Com_analyze | 0 |
| Com_backup_table | 0 |
| Com_begin | 0 |
| Com_change_db | 3238 |
| Com_change_master | 0 |
| Com_check | 0 |
| Com_commit | 0 |
| Com_create_db | 0 |
| Com_create_function | 0 |
| Com_create_index | 0 |
| Com_create_table | 0 |
| Com_delete | 249 |
| Com_drop_db | 0 |
| Com_drop_function | 0 |
| Com_drop_index | 0 |
| Com_drop_table | 0 |
| Com_flush | 0 |
| Com_grant | 0 |
| Com_insert | 404 |
| Com_insert_select | 16 |
| Com_kill | 0 |
| Com_load | 0 |
| Com_load_master_table | 0 |
| Com_lock_tables | 0 |
| Com_optimize | 0 |
| Com_purge | 0 |
| Com_rename_table | 0 |
| Com_repair | 0 |
| Com_replace | 23 |
| Com_replace_select | 1 |
| Com_reset | 0 |
| Com_restore_table | 0 |
| Com_revoke | 0 |
| Com_rollback | 0 |
| Com_select | 77484 |
| Com_set_option | 0 |
| Com_show_binlogs | 0 |
| Com_show_create | 0 |
| Com_show_databases | 1 |
| Com_show_fields | 0 |
| Com_show_grants | 0 |
| Com_show_keys | 0 |
| Com_show_logs | 0 |
| Com_show_master_stat | 0 |
| Com_show_open_tables | 0 |
| Com_show_processlist | 0 |
| Com_show_slave_stat | 0 |
| Com_show_status | 961 |
| Com_show_tables | 0 |
| Com_show_variables | 3 |
| Com_slave_start | 0 |
| Com_slave_stop | 0 |
| Com_truncate | 0 |
| Com_unlock_tables | 0 |
| Com_update | 10211 |
| Connections | 2291 |
| Created_tmp_disk_tables | 5 |
| Created_tmp_tables | 1373 |
| Created_tmp_files | 0 |
| Delayed_insert_threads | 0 |
| Delayed_writes | 0 |
| Delayed_errors | 0 |
| Flush_commands | 1 |
| Handler_delete | 360 |
| Handler_read_first | 2953 |
| Handler_read_key | 302790 |
| Handler_read_next | 1131725 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 396000 |
| Handler_read_rnd_next | 29448095 |
| Handler_update | 13862 |
| Handler_write | 42839 |
| Key_blocks_used | 2735 |
| Key_read_requests | 1432150 |
| Key_reads | 2729 |
| Key_write_requests | 2514 |
| Key_writes | 2275 |
| Max_used_connections | 56 |
| Not_flushed_key_blocks | 0 |
| Not_flushed_delayed_rows | 0 |
| Open_tables | 64 | 100% of table_cache in use
| Open_files | 88 |
| Open_streams | 0 |
| Opened_tables | 705 |
| Questions | 93880 |
| Select_full_join | 5 |
| Select_full_range_join | 0 |
| Select_range | 15187 |
| Select_range_check | 0 |
| Select_scan | 35722 |
| Slave_running | OFF |
| Slave_open_temp_tables | 0 |
| Slow_launch_threads | 0 |
| Slow_queries | 244 | (execution time > 10 secs)
| Sort_merge_passes | 0 |
| Sort_range | 14563 |
| Sort_rows | 397534 |
| Sort_scan | 29636 |
| Table_locks_immediate | 97612 |
| Table_locks_waited | 109 |
| Threads_cached | 0 |
| Threads_created | 2290 |
| Threads_connected | 12 |
| Threads_running | 2 |
| Uptime | 7659 | 2 hrs 7 mins 39 secs
+--------------------------+-----------+


Key Reads/Key Read Requests = 0.001906 (Cache hit = 99.998094%)
Key Writes/Key Write Requests = 0.904932
Connections/second = 0.299 (/hour = 1076.851)
KB received/second = 1.578 (/hour = 5681.786)
KB sent/second = 20.612 (/hour = 74201.645)
Temporary Tables Created/second = 0.179 (/hour = 645.358)
Opened Tables/second = 0.092 (/hour = 331.375)
Slow Queries/second = 0.032 (/hour = 114.689)
% of slow queries = 0.260%
Queries/second = 12.257 (/hour = 44126.910)

это ты при помощи чего делал, а то мне хостер жалуется что этот домен ему проц грузит, а я не понимаю откуда это может исходить.

__________________
Всегда есть решение.

в сочетании с phpinfo великолепная штука

а что вообще может тормозить? ну подумаешь несколько хаков создают, скажем, 20 лишних запросов к базе, это же не критично в общем. я ошибаюсь? неопределенные переменные в шаблонах от пустых хаков? нет.

да нет не это имеется ввиду, может быть например бесконечный цикл - ошибка при программировании.

__________________
Всегда есть решение.

polo как можно отдебагить код? хотя я жду 3-ю версию, тогда все хаки буду с нуля ставить, благо их не так много у меня

дебаггером можно http://dd.cron.ru/dbg/

__________________
Всегда есть решение.

Я правда vb не занимаюсь, но если провести аналогию с проблемами возникающими в сети, то возможно такая низкая производительность, не связанная с загрузкой проца, вызвана частыми или завышенными таймаутами???

__________________
Администратор Бед в Данных...

Kizalkoatl ты их наблюдал на нетадмине?

__________________
Всегда есть решение.

Нет.. никогда.

Kizalkoatl добавил 26-12-2002 в 15:35:01:
Мне тут в голову пришло...
Ежели снижение производительности вызваны программными ошибками типа циклов и т.д. как ты Polo сказал, то это отразится в завышеном CPS, а низкая производительность из-за таймаутов и др. задержек вобще CPS ни как жрать не будет. Можно отловить.

__________________
Администратор Бед в Данных...

пока не отловил, в логах апача тревожат строки
>client stopped connection before send body completed
>Broken pipe: client stopped connection before rwrite completed
и т.д.

Bochkarev_D.S. добавил 27-12-2002 в 05:06:27:
пробовал "чистые" файла vb, тормозит, значит либо в базе либо в темплейте траблы

Bochkarev_D.S. добавил 27-12-2002 в 05:17:35:
и все это на фоне загрузки
-->>> 0.34, 0.19, 0.18 | 34 users online (30 members & 4 guests).
фак, я так не могу уже.

Ну в сети Ethernet это обычно бывает так, если флудит один адаптер, то любой другой при попытке установить коннект, посылает сигнал и наталкивается на флуд другого адаптера,
происходит коллизия, и что бы ее разрешить адаптер поднимает флаг таймаута на случайный промежуток времени, но другой то флудит с не нормальным интервалом и при повторной попытке (если адаптер не поподает в спокойный интервал) происходит то же самое - это называется вынужденное затишье, пропускная способность еще вооогого, а производительность уже никакая. Все это конечно может не относится к данной проблеме, но думается мне что характер данного трабла один и тот же. Вот скажем
>client stopped connection before send body completed
>Broken pipe: client stopped connection before rwrite completed
могут запросто вызывать какие нибудь Time_wait и т.д. вопрос в том вызывают ли? часто ли? и по какой причине?
Аналогичные ошибки могут быть в коде. Надо отлавливать.

__________________
Администратор Бед в Данных...

вот тут чем все это закончилось
http://www.netadmin.ws/forum/showthread.php?s=&threadid=3937