Mac

Да, нашел один очень страшный запрос в базу на главной странице. Убрал - существенно полегчало. с сессиями стоит мод для их ограничения и автоочистки. Видимо, не успевает просто очистить при большом количестве подключений.Одновременных сессий стоит 160. На один ip - 2 сессии. Можно попробовать повысить первый показатель, но, боюсь, нагрузка возрастет.

Сегодня на Улановке были некоторые глюки. Все дело в том, что я проводил обновление версии движка. Подобное обновление впереди еще предстоит не раз. Сейчас отлавливаем глюки. Один с отправкой ЛС уже нашли и исправили. Обо всех замеченных ошибках просьба уведомлять в этом форуме. Еще одна хорошая новость. В ходе работы над оптимизацией кода был найден неоптимальный его кусок, который существенно нагружал базу форума. Сейчас облегчение налицо. Сегодня, думаю, вы заметили это.

исправил.

Надо бы проверить эту инфу или самим эмпирическим путем, или от администрации СТК.

олбанец!

о-О! Это что, новые ip-диапазоны Сибирьтелекома?

И тишина... Вот тут конкретно с торрентпировского форума админ пишет: И вот выдержка из статьи по оптимизации сервера: Источник. В данный момент эти параметры у нас по дефолту: query_alloc_block_size 8192 query_cache_limit 1048576 query_cache_min_res_unit 4096 query_cache_size 0 query_cache_type ON query_cache_wlock_invalidate OFF query_prealloc_size 8192 table_cache 64 key_buffer_size 8388600 max_connections 100 Системные переменные MySQL сервера: Переменные сервера значения переменных back_log 50 basedir /usr/ bdb_cache_size 8388600 bdb_home /var/lib/mysql/ bdb_log_buffer_size 32768 bdb_logdir bdb_max_lock 10000 bdb_shared_data OFF bdb_tmpdir /tmp/ binlog_cache_size 32768 bulk_insert_buffer_size 8388608 character_set_client cp1251 character_set_connection cp1251 character_set_database cp1251 character_set_results cp1251 character_set_server cp1251 character_set_system utf8 character_sets_dir /usr/share/mysql/charsets/ collation_connection cp1251_swedish_ci collation_database cp1251_general_ci collation_server cp1251_general_ci concurrent_insert ON connect_timeout 5 datadir /var/lib/mysql/ date_format %Y-%m-%d datetime_format %Y-%m-%d %H:%i:%s default_week_format 0 delay_key_write ON delayed_insert_limit 100 delayed_insert_timeout 300 delayed_queue_size 1000 expire_logs_days 0 flush OFF flush_time 0 ft_boolean_syntax + -><()~*:""&| ft_max_word_len 84 ft_min_word_len 4 ft_query_expansion_limit 20 ft_stopword_file (built-in) group_concat_max_len 1024 have_archive NO have_bdb YES have_blackhole_engine NO have_compress YES have_crypt YES have_csv NO have_example_engine NO have_geometry YES have_innodb YES have_isam YES have_ndbcluster NO have_openssl YES have_query_cache YES have_raid NO have_rtree_keys YES have_symlink YES init_connect init_file init_slave innodb_additional_mem_pool_size 1048576 innodb_autoextend_increment 8 innodb_buffer_pool_awe_mem_mb 0 innodb_buffer_pool_size 8388608 innodb_data_file_path ibdata1:10M:autoextend innodb_data_home_dir innodb_fast_shutdown ON innodb_file_io_threads 4 innodb_file_per_table OFF innodb_flush_log_at_trx_commit 1 innodb_flush_method innodb_force_recovery 0 innodb_lock_wait_timeout 50 innodb_locks_unsafe_for_binlog OFF 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_max_dirty_pages_pct 90 innodb_max_purge_lag 0 innodb_mirrored_log_groups 1 innodb_open_files 300 innodb_table_locks ON innodb_thread_concurrency 8 interactive_timeout 28800 join_buffer_size 131072 key_buffer_size 8388600 key_cache_age_threshold 300 key_cache_block_size 1024 key_cache_division_limit 100 language /usr/share/mysql/english/ large_files_support ON license GPL local_infile ON locked_in_memory OFF log OFF log_bin OFF log_error log_slave_updates OFF log_slow_queries OFF log_update OFF log_warnings 1 long_query_time 10 low_priority_updates OFF lower_case_file_system OFF lower_case_table_names 0 max_allowed_packet 1048576 max_binlog_cache_size 4294967295 max_binlog_size 1073741824 max_connect_errors 10 max_connections 100 max_delayed_threads 20 max_error_count 64 max_heap_table_size 16777216 max_insert_delayed_threads 20 max_join_size 4294967295 max_length_for_sort_data 1024 max_relay_log_size 0 max_seeks_for_key 4294967295 max_sort_length 1024 max_tmp_tables 32 max_user_connections 0 max_write_lock_count 4294967295 myisam_data_pointer_size 4 myisam_max_extra_sort_file_size 2147483648 myisam_max_sort_file_size 2147483647 myisam_recover_options OFF myisam_repair_threads 1 myisam_sort_buffer_size 8388608 net_buffer_length 16384 net_read_timeout 30 net_retry_count 10 net_write_timeout 60 new OFF old_passwords ON open_files_limit 1024 pid_file /var/run/mysqld/mysqld.pid port 3306 preload_buffer_size 32768 protocol_version 10 query_alloc_block_size 8192 query_cache_limit 1048576 query_cache_min_res_unit 4096 query_cache_size 0 query_cache_type ON query_cache_wlock_invalidate OFF query_prealloc_size 8192 range_alloc_block_size 2048 read_buffer_size 131072 read_only OFF read_rnd_buffer_size 262144 relay_log_purge ON relay_log_space_limit 0 rpl_recovery_rank 0 secure_auth OFF server_id 0 skip_external_locking ON skip_networking OFF skip_show_database OFF slave_net_timeout 3600 slave_transaction_retries 0 slow_launch_time 2 socket /export/var/lib/mysql/mysql.sock sort_buffer_size 2097144 sql_mode storage_engine MyISAM sql_notes ON sql_warnings ON sync_binlog 0 sync_replication 0 sync_replication_slave_id 0 sync_replication_timeout 0 sync_frm ON system_time_zone IRKT table_cache 64 table_type MyISAM thread_cache_size 0 thread_stack 196608 time_format %H:%i:%s time_zone SYSTEM tmp_table_size 33554432 tmpdir transaction_alloc_block_size 8192 transaction_prealloc_size 4096 tx_isolation REPEATABLE-READ version 4.1.12 version_bdb Sleepycat Software: Berkeley DB 4.1.24: (May 13, 2005) version_comment Source distribution version_compile_machine i686 version_compile_os redhat-linux-gnu wait_timeout 28800

Ghost in the Shell

, да

еще бы! Это чтобы я не узнал этот трепещущий душу момент, когда ждешь, какой же покемон у противника Эша!

Покемона!

угу

Борюсь с нагрузкой, уменьшая запросы к базе. Если проблемы с нагрузкой будут решены, список вернется.

я даже участвовал в озвучке Хроник Но в итоге выбрали голос самого Трансматрикса, а мой забраковали, хотя йа, имхо, гораздо более эмоционально озвучил типка из команды "R" *pactalomСабить мона бы припахать каких-нить ФИЯшников. Заодно на бурятский пусть пеерведут - покажем все кузькину мать! В Бурятии великовозрастные фанаты Покемона впервые в СНГ перевели и озвучили все сезоны сериала... на бурятский *pactalom

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

Вот phpinfo()

Товарищи! Отечество в опасности! Обращаюсь ко всем, кто хоть как-то связан с администрированием веб-серверов и программированием с просьбой о помощи. Как вы все видите, уже не первый месяц вечером на Улановку зайти становится все сложнее из-за нагрузки на сервер. В чем причина. Давайте разберемся вместе! Для начала опишу отброшенные гипотезы: [*:d7149e892e]Загрузка канала. Возможной причиной тормозов могли быть забитые каналы, но в этом случае страницы генерировались штатно быстро, а загружались бы медленно (по частям). Это мы не наблюдаем, и слава богу. [*:d7149e892e]Маломощность серверного "железа". Администратор форума Сибирьтелекома любезно предоставил нам конфигурацию "железа". Это действительно неслабая машина. Ее теоретически должно хватать для правильной работы веб-сервера с нашей нагрузкой (при правильной его настройке, конечно). Основных гипотез две: [*:d7149e892e]Ошибки и неоптимальный код движка. Сисадмины Сибирьтелекома, на серверах которого физически находится трекер, придерживаются именно ее, полагая, что дело в самом форумном движке phpBB, который не является лучшим выбором для подобного проекта. Я, честно говоря, не совсем согласен с этим утверждением, аргументируя это тем фактом, что phpBB используется во всем мире и входит в тройку самых популярных форумных движков. Существует множество форумов с куда большей посещаемостью, которые не страдают такими пролемами. Также скажу, что перелопатил все русское сообщество phpbb в тщетных попытках найти ответ на свой вопрос. Всевозможные мелкие уловки и хаки для оптимизации уже установлены (# кэширование, использование динамических HEAP-таблиц для хранения сессий, ограничение количества сессий, включение/выключение сжатия gzip и пр.). [*:d7149e892e]Неправильная (неоптимальная) настройка сервера. Я сам склоняюсь к этому мнению. В администрировании веб-серверов я, к сожалению, не силен, потому опираюсь лишь на свои дилетантские знания и гугл. Поэтому прошу людей знающих подсказать возможные пути решения проблемы в этом направлении. Конфигурацию сервера (phpinfo) предоставлю, может она прольет свет на возможные причины тормозов. К слову скажу, что недавно исправленная ошибка с загрузкой аватаров на сервер была связана именно с ошибкой в настройке веб-сервера - неправильно установленной директивой open_basedir в php.ini. Прошу программистов помочь разобраться в первой теории, а системщиков - поработать во втором направлении. Уверен, вместе мы найдем причину и устраним ее! График распределения нагрузки на сервер по времени суток выглядит примерно так: Как видно из рисунка, максимальный пик попадает на промежуток с 18.00 вечера до 00.00. А минимальная нагрука приходится на 5-6 утра. В данной теме прошу писать только свои трезвые предложения и толковые мысли, без оффтопа, а также прошу воздержаться от оскорблений администрации Сибирьтелекома.

Уважаемый Crot, очень ценю ваш совет. Но не могу последовать ему, точнее не рискую. База в данный момент весит >150 мегабайт. С такими масштабами едва ли можно быть уверенным в успешности sql-запросов. А если еще учитывать огромную нагрузку на базу, то вероятность благоприятного исхода резко падает. В любом случае обязательно возьму на заметку ваш код. З.Ы. Нам очень нужны такие опытные люди, кто может помочь квалифицированным советом.

Возрадуйтесь, товарищи. Наконец-то через 7 месяцев после рождения Улановки налажена загрузка аватаров! Ограничения довольно жесткие: 10 Кб и по-прежнему 100*100 размер. Обусловлено это малым дисковым пространством под трекер. Но зато теперь не надо переживать за "умершие" аватары.

если бы это было у меня одного, я бы сперва проверил свою Оперу на глючность. надо что?

а как вас собсна найти?А группа - вот она http://vkontakte.ru/club603880 З.Ы. Наталья, уберите аватар с внешки. Это строго запрещено. Перелейте во внутреннюю сеть (ftp.burnet.ru или галерея Стбура).

Вот ссылка: http://sanek2008.my1.ru/. Разберите там между собой и качайте 4-й сезон. из всего адреса самое сложное запомнил

Внимание! Завтра 30 января в 10 часов утра будет изменена конфигурация сервера. Есть вероятность, что какое-то время сайт не будет доступен. Не волнуйтесь, изменения плановые.

Я работаю над этим, не беспокойтесь.

Докуро-тян?