Перейти к контенту

MIl

Пользователи
  • Число публикаций

    11
  • Регистрация

  • Последнее посещение

Недавние посетители профиля

717 просмотров профиля

Достижения MIl

  1. Да, похоже придётся перейти обратно на MyISAM. Ступор базы стабильно случается как минимум 2 раза в сутки. Во всех случаях замеченная мной причина ступора - один запрос с count(*) к таблице ibf_posts, которую я и конвертнул в InnoDB. Был проведён нехитрый тест (на другой машине) - запрос "SELECT COUNT(*) from ibf_posts;". Тип таблицы InnoDB (разные уровни изоляции на скорости никак не отразились): mysql> SELECT COUNT(*) from ibf_posts; +----------+ | COUNT(*) | +----------+ | 2198861 | +----------+ 1 row in set (52.06 sec) Теперь конвертим ту же таблицу обратно в MyISAM: mysql> alter table ibf_posts type=myisam; Query OK, 2198861 rows affected, 1 warning (4 min 44.89 sec) Records: 2198861 Duplicates: 0 Warnings: 0 И запускаем тот же запрос: mysql> SELECT COUNT(*) from ibf_posts; +----------+ | COUNT(*) | +----------+ | 2198861 | +----------+ 1 row in set (0.01 sec) Разница между временем выполнения запроса просто поразительная - 52 секунды для InnoDB и 0.01 секунды для MyISAM. Впечатления от медленной работы базы в InnoDB повторяют впечатления о большем объёме занимаемого базой места на диске - везде сказано что больше, но не настолько же! И если использование диска большее в 2,5 раза ещё можно терпеть, то медлительность большую на несколько порядков терпеть никак не получается. Дополнение. Кажется виновный в ступоре запрос найден и найдена функция, использующая этот запрос. Запрос из файла sources/sql/mysql_queries.php: function buddy_posts_last_visit( $a ) { return "SELECT COUNT(*) as posts FROM ".SQL_PREFIX."posts p USE INDEX (topic_id) LEFT JOIN ".SQL_PREFIX."topics t ON (p.topic_id=t.tid) WHERE t.forum_id IN({$a['forum_string']}) AND p.queued=0 AND p.post_date > {$a['last_visit']}"; } Функция function buddy_posts_last_visit используется при открытии "Помощника". Я не нашёл ответа можно ли как-то переделать этот запрос, чтобы он работал с InnoDB таблицей быстрее, так что я просто удалил использование этой функции и всё, т.к. не считаю её необходимой. Закомментировал строчки вызова функции в файле sources/action_public/browsebuddy.php и отображение количества новых сообщений в шаблонах. Надеюсь это позволит избежать ступоров базы.
  2. IPB 2.1.7. Часто падала таблица ibf_posts. Таблица с 2,2 миллиона записей и занимала на диске чуть больше 1ГБ не считая фултекст индекса. Перевёл её из MyISAM в InnoDB. Фуллтекст индекс конечно удалил. Как я писал выше раньше таблица ibf_posts занимала на диске примерно 1 гиг, не считая индексов. Исходя из этой цифры для InnoDB решил указать три файла по 500 метров, последний с авторасширением, типа с запасом и не сильно большие файлы. И что я вижу после конвертирования - все три файла по 500 метров заполнены и последний авторасширился почти до 1,4 гига! 524288000 - ibdata0 524288000 - ibdata1 1488977920 - ibdata2 Это же в 2,5 раза больше, чем было с MyISAM! Нет я читал, что InnoDB занимает больше места, но я не предполагал что настолько! Пришлось добавить ещё один файл данных размером с уже авторасширевшийся файл (1420М) и того у меня сейчас уже 4 файла данных: 524288000 - ibdata0 524288000 - ibdata1 1488977920 - ibdata2 524288000 - ibdata3 Это нормально? Как у вас?
  3. Привет. Есть достаточно нагруженный форум: - 1800967 сообщений; - в дневное время около 500 посетителей за 15 минут; При массовом сокращении тем из какого-либо раздела зачастую повреждаются таблицы БД, чаще всего ibf_posts. Думал может конфликт с запросами других клиентов - попробовал закрыть доступ к форуму всем и запустить массовое удаление - то же самое, с частотой примерно 1 раз в 3-5 попыток возникают проблемы с таблицами. Удаление запускаю частями - 200-300 тем, по 50 за один цикл. Так что процесс не занимает очень много времени, т.е. в лимит выполнения скриптов, думаю, укладывается. Есть ли ещё у кого-либо такие проблемы или это у меня что-то криво работает? Спасибо.
  4. Про "другие механизмы поиска" сейчас поищу информацию. Насчёт Апача. Пробовал nginx и php как fastcgi - не работало быстрое редактирование сообщений (а может и ещё что-то), пришлось отказаться. Попробую ещё раз. Кстати, все картинки и аплоады раздаются nginx-ом, который висит на дополнительном айпишнике на этом же сервере. Мускл настроен неправильно? Допускаю. Тогда скажите что именно неправильно. mysql41-server собран из портов: WITH_CHARSET=koi8r WITH_COLLATION=koi8r_general_ci \ WITH_LINUXTHREADS=yes WITH_PROC_SCOPE_PTH=yes \ BUILD_OPTIMIZED=yes BUILD_STATIC=yes \ make install В файле /etc/libmap.conf указан маппинг: liblthread.so.3 libthr.so.2 В стандартном /etc/my.cnf изменены следующие опции: max_connections=300 skip-locking skip-external-locking skip-innodb key_buffer = 384M max_allowed_packet = 1M table_cache = 512 sort_buffer_size = 24M myisam_sort_buffer_size = 24M read_buffer_size = 2M read_rnd_buffer_size = 8M thread_cache_size = 38 query_cache_size = 16MB tmp_table_size = 32MB record_buffer = 4M net_buffer_length = 16K wait_timeout=60 interactive_timeout=60 flush_time=3600 Все файлы с базой находятся на втором диске, кроме файлов ibf_topic_markers.MYD и ibf_topic_markers.MYI, которые, для более равномерного использования дисков, перенесены на первый диск. Все таблицы в MyISAM, кроме ibf_sessions - она в HEAP. Какая информация ещё нужна?
  5. Интересное дополнение. Только сейчас обратил внимание на график количества операций чтения с дисков. По нему видно, что во время работа форума на версии 2.2.2, кроме loadaverage сильно выросло и кол-во операций чтения с дисков. А точнее их стало раз в 5 больше, чем обычно. При этом на графике операций записи на винты заметного роста нет, за исключением пары непродолжительных пиков. Т.к. на втором винте (SATA) у меня только БД, получается, что скорее всего мускл тормозил просто из-за большого кол-ва чтений из базы, которые винт просто не успевал обслужить. Отсюда напрашивается вывод, что в новой версии сильно выросло кол-во обращений к базе.
  6. Master О каком именно кешировании вы говорите? В самом движке? PHP-кеш у меня стоит - Turck MMCache. Об отдельном БД-сервере думал, вопрос в деньгах, которых хватит на такую машинку, которая, уверен, проблему не решит. Если движок в состоянии так легко загрузить указанную мной машину, то мне нужно что-то с 4-мя процами, 4 гигами ОЗУ и сказёвым раид массивом, что-бы форум нормально работал ещё хоть с годик ) Ну да ладно, это уже лирика ) Насчёт Постгре. Самое большое что меня беспокоит это необходимость конвертирования базы, а такая необходимость как мне кажется есть. Интересно знать сколько будет конвертиться таблица ibf_posts c более чем 2 млн. записей? Также беспокоит небольшая популярность Постгре для ИПБ, это вполне логично наводит на мысли о худшей поддержке и меньшей отлаженности. Подводя итог скажу, что на данный момент я принял решение оставаться на версии 2.1.7 до тех пор пока не будут найдены ресурсы на сервер, на много превосходящий существующий по производительности.
  7. То что новый движок с кучей новых фич требует больше ресурсов это понятно. При переезде с 1.3 на 2-ю версию нагрузка возрасла, но осталась допустимой. А тут... Мне просто важно выяснить для себя что это было - проблема, вызванная некими неправильными действиями по обновлению, или это вовсе и не проблема, а закономерный результат работы нового движка.
  8. Хочу поделиться моей печальной историей по переходу с 2.1.7 на 2.2.2. Имеется: - выделенный сервер под форум - P4 3.2Ghz, RAM 2GB, 2 разных винта с разнесёнными по ней некоторыми таблицами базы и сайтом. FreeBSD 6.2, MySQL 4.1.22 (libthr), php 4.4.4 (apache2handler). - форум версии 2.1.7 c примерно 500 посетителей за 15 минут в рабочее время и вот такой прочей статистикой: На форуме сообщений: 1748011 Зарегистрировано пользователей: 10775 Рекорд посещаемости форума - 1063, зафиксирован - 19.6.2006, 15:29 Сам процесс обновления проходил достаточно спокойно. Была одна заморочка со стилями - хотя я и указал инсталлятору, что можно удалить всё что ему вздумается, но после установки оказалось, что, ни старые, ни новые стили нормально не отображались - почти все управляющие надписи отсутствовали. Я потратил часа полтора-два на эту проблему. Пришлось поставить на другой машине новую версию на чистую и импортнул оттуда стиль на боевой сервер, но это проблемы не решило. А решило проблему импортирование русского языка с чистой инсталляции. Естесственно я перед обновлением удалил со старой версии всё, кроме конфига и аплоадов. Вероятно инсталлятор создал новый набор на основании старых данных из БД, а больше им взяться было неоткуда. Ещё одна заморочка, которая не имеет прямого отношения к движку, но которая теоритически могла в какой-то мере повлиять на работу форума после обновления, это путаница с кодировками. Исторически так получилось, что у меня и скрипты и база были в кои8р, т.к. так проще работать со скриптами и базой из юниксовой консоли. Ну а так как русифицированный форум поставлялся в кондировке цп1251, то каждый раз перед обновлением мне приходилось переконвертить скрипты в кои8р. В этот раз я решил оставить срипты в цп1251, а базу в кои8р, потому привести их к одной и той же кодировке было затруднительно. В принципе мне это удалось, за несколькими исключениями из АдминПанели, которые мне пришлось перекодировать вручную и перезалить в БД. Эту заморочку я описываю потому, что допускаю, что перекодировка данных в и из БД занимала некоторые ресурсы сервера. В самом конце обновления инсталлятор порекомендовал обновить информацию о сообщениях и аттачментах через АдминПанель. И, хотя с виду с сообщениями было всё нормально, я запустил этот процесс. Но его пришлось прервать, т.к. он проходил чрезвычайно медленно - за 2-3 часа было обратано не более 200 тысяч из почти 1,7 млн. сообщений. Это тоже теоритически могло повлиять на скорость работы форума. После запуска форума в работу появились настоящие проблемы - при нагрузке раза в 2-3 меньше обычной форум жутко тормозил, а система была загружена выше всяких разумных пределов. В юниксах есть такое понятие как LoadAverage - количество процессов, ожидающих получения ресурсов системы. В нормальном случае этот показатель не должен быть больше единицы. На моём сервере LA со старой версией в пиках достигал и 10-ти, а обычно был меньше 5-ти, причём это было ещё снижение после массы танцев с бубеном вокруг системы. Так вот, LA на той же системе с новым движком весь день колебалась между 30-тью и 50-тью! Ну и о нормальной работе с форумом конечно речи не было. Судя по всему MySQL просто перестал справляться с новой нагрузкой, о чём свидетельствовало почти постоянный длинный список процессов СУБД. Всё остальное, включая MySQL, осталось тоже самое, так что под подозрением оставался только новый движок. И вот из старых копий, сделанных перед обновлением, всё было возвращено обратно, завелось с пол-пинка и просто летает. Несмотря на то, что у нас уже почти восемь часов вечера на форуме больеш 300 человек и тот самый LA колеблется между 2-мя и 4-мя, т.е. при примерно том же количестве посетителей в онлайне нагрузка системы со старым движком на порядок меньше. Вот такая история. Я уже назвал все свои действия, которые теоритически могли привести к описанной ситуации, но хотелось бы знать наверняка где я накосячил.
  9. Два вопроса: 1. Интересуют впечатления уже проапгрейдившихся товарищей о скорости конвертирования таблицы ibf_posts. Я не так давно на локальной машине пытался обновится с 2.1.7рус до 2.2.1ингиш. На этапе конвертирования таблицы ibf_posts, которая у меня содержит чуть больше 2 млн. записей, процесс ушёл в астрал и не вышёл из него за весь день, при этом видно было, что активность есть - файлы БД меняются. 2. В списке новостей ничего не сказано про оптимизацию. Поэтому меня интересуют впечатления, пусть и субъективные, по поводу наличия/отсутствия заметных замедлений/ускорений по сравнению с 2.1.7. Спасибо.
×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.