Удаление папки /install/ - обязательно!

Файловый Архив

  • Неограниченное количество категорий и суб-категорий
  • Настройки прав доступа по группам
  • Настройки прав доступа по каждой категории
  • Предпросмотр медиа файлов: FLV, IFLV, F4A, F4V, MP4, MP3, MOV и других...
  • Мультизагрузка файлов - SWFUploader
  • Добавление файлов с сервера
Подробности и история обновлений продукта в этой теме
Loading

Go Back   форум vBSupport.org > > >
Register Изображения Меню vBsupport Files Manager Аллея Звёзд Реклама на форуме Search Today's Posts Mark Forums Read
  • Мемберка
  • Администраторам
  • Premoderation
  • For English speaking users
  • Изменения в правах
  • Каталог Фрилансеров
Пароли на скачивание файлов в Member Area меняются автоматически каждый день
Если вам нужно скачать какой то скрипт, за паролем ко мне в ЛС
привет какирам kerk
Ещё раз обращаем Ваше внимание: всё, что Вы скачиваете и устанавливаете на свой форум, Вы устанавливаете исключительно на свой страх и риск.
Сообщество vBSupport'а физически не в состоянии проверять все стили, хаки и нули, выкладываемые пользователями.
Помните: безопасность Вашего проекта - Ваша забота.
Убедительная просьба: при обнаружении уязвимостей или сомнительных кодов обязательно отписывайтесь в теме хака/стиля
Спасибо за понимание
На форуме введена премодерация ВСЕХ новых пользователей

Почта с временных сервисов, типа mailinator.com, gawab.com и/или прочих, которые предоставляют временный почтовый ящик без регистрации и/или почтовый ящик для рассылки спама, отслеживается и блокируется, а так же заносится в спам-блок форума, аккаунты удаляются
for English speaking users:
You may be surprised with restriction of access to the attachments of the forum. The reason is the recent change in vbsupport.org strategy:

- users with reputation < 10 belong to "simple_users" users' group
- if your reputation > 10 then administrator (kerk, Luvilla) can decide to move you into an "improved" group, but only manually

Main idea is to increase motivation of community members to share their ideas and willingness to support to each other. You may write an article for the subject where you are good enough, you may answer questions, you may share vbulletin.com/org content with vbsupport.org users, receiving "thanks" equal your reputation points. We should not only consume, we should produce something.

- you may:
* increase your reputation (doing something useful for another members of community) and being improved
* purchase temporary access to the improved category:
10 $ for 3 months. - this group can download attachments, reputation/posts do not matter.
20 $ for 3 months. - this group can download attachments, reputation/posts do not matter + adds eliminated + Inbox capacity increased + files manager increased permissions.

Please contact kerk or Luvilla regarding payments.

Important!:
- if your reputation will become less then 0, you will be moved into "simple_users" users' group automatically.*
*for temporary groups (pre-paid for 3 months) reputation/posts do not matter.
Не можете скачать вложение?
Изменения в правах групп пользователей
внимательно читаем эту и эту темы
Короткая версия - тут
Уважаемые пользователи!

На форуме открыт новый раздел "Каталог фрилансеров"

и отдельный раздел для платных заказов "Куплю/Закажу"

 
 
Old  
tarasus
Простоузер
Default [3.8.1] Тормозит MySQL при исполнении запросов 0

Доброго всем времени суток и праздничного настроения!

Как обычно, не прошло и 16 миллиардов лет, как моя скромная персона снова взывает к помощи великих мастеров укрощаемого форумного движка.
Имеется 3.8.1 лицензия. Одновременно сидящих пользователей, включая "гостей", обычно около 1500. Сервер - не сказал бы, что тухлый: 16 гектар для памяти, SAS 250 в зеркале на LSI Logic, 4 аппаратных проца, самцы (двухъядерные).
Мускль 5.0.95, пых 5.3.х.
Часть таблиц сконвертирована в InnoDB (в которых нет необходимости организовывать полнотекстовый индекс), часть, например, vb3_post и vb3_thread - в myISAM.
И так всё лабало порядка трёх лет: аптайма на сервере по состоянию на позавчера было 890 дней. Вдруг начались тормоза. В системе начали плодиться процессы апача, причём особо не отнимая ни процессорное время, ни память, а в мускле толпилась очередь из запросов. Протоколирование "длинных" запросов показало, что практически все запросы мускль исполняет как "длинные".

Например, запрос

PHP Code:
pmtext.pmtextid FROM vb3_pmtext AS pmtext LEFT JOIN vb3_pm AS pm USING(pmtextidWHERE pm.pmid IS NULL 
стоял в очереди около 700 секунд.

Просмотр общего состояния системы говорит, что дисковая подсистема загружена на 100%, а операций ввода/вывода исполняется чуть больше 200/сек, что очень мало.
Обращение напрямую к рэйд-контроллеру и дискам через рэйд-утилиту на предмет просмотра статуса задач показывает, что текущих задач по контроллеру и по дискам нет.

"Тормоза" могут длиться как час, так и полдня. Потом опять же "внезапно" очередь запросов начинает разгребаться, "ожидающие ответа" процессы апача умирать своей смертью, мускль начинает шустро отдавать данные, по дисковой подсистеме производительность становится 3500+транзакций/сек и форум начинает летать.

В общем, ситуация для меня не совсем ясная.

Планирую сейчас смигрировать на Mysql 5.6 и сконвертить оставшиеся таблицы в InnoDB. Сейчас этого сделать нельзя, т.к. текущая версия мускля не поддерживает полнотекстовый индекс, а начиная с 5.6 InnoDB уже умеет это делать.

Буду рад любым советам. Спасибо.
Всем добра, чистой кармы и хороших финансовых вливаний!
 
Bot
Yandex Bot Yandex Bot is online now
 
Join Date: 05.05.2005
Реклама на форуме А что у нас тут интересного? =)
Old  
eska
Специалист
 
eska's Avatar
Default 1

Попробуйте начать со smartctl для дисков и mysqltuner.pl для MySQL.
 
Old  
mindframe
Специалист
 
mindframe's Avatar
Default 1

@tarasus, по теме посоветовать особо не могу, но раз собрались мигрировать, то можете посмотреть в сторону percona как пример.
 
Old  
tarasus
Простоузер
Default 0

диски SASовские, там смарта нет, но за идею спасибо
 
Old  
hoo
Мастер
 
hoo's Avatar
Default 3

Запрос, который указан в примере это из includes/cron/cleanup2.php
Code:
// Orphaned pmtext records are removed after one hour.
// When we delete PMs we only delete the pm record, leaving
// the pmtext record alone for this script to clean up
$pmtexts = $vbulletin->db->query_read("
	SELECT pmtext.pmtextid
	FROM " . TABLE_PREFIX . "pmtext AS pmtext
	LEFT JOIN " . TABLE_PREFIX . "pm AS pm USING(pmtextid)
	WHERE pm.pmid IS NULL
");
Бардак с личками?
Выполните запрос в phpMyAdmin
Code:
EXPLAIN SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext
LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL;
 
Old  
tarasus
Простоузер
Default 2

Это первая попавшаяся строка из mtop - утилиты, просматривающей процессы, творящиеся в мускле; из пятисот запросов, стоящих в очереди, можно было бы выбрать любой другой, просто этот покороче и помещается на длину экрана Да и смущает как раз то, что он вроде бы короткий, а выполняется так долго.
С личками вроде бы всё в порядке.
Прогнал сейчас дополнительно через админку оптимизацию/восстановление баз. Некоторые ошибки были обнаружены, хотя та же самая процедура, но средствами мускля, говорила ok.
Посмотрим, как дальше будет жить.

tarasus добавил 07.05.2015 в 11:11
Quote:
Originally Posted by hoo View Post
Бардак с личками?
Выполните запрос в phpMyAdmin
Code:
EXPLAIN SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext
LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL;
Code:
mysql> EXPLAIN SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL;
+----+-------------+--------+-------+---------------+----------+---------+-------------------------+--------+--------------------------------------+
| id | select_type | table  | type  | possible_keys | key      | key_len | ref                     | rows   | Extra                                |
+----+-------------+--------+-------+---------------+----------+---------+-------------------------+--------+--------------------------------------+
|  1 | SIMPLE      | pmtext | index | NULL          | PRIMARY  | 4       | NULL                    | 501957 | Using index                          |
|  1 | SIMPLE      | pm     | ref   | pmtextid      | pmtextid | 4       | pr_last.pmtext.pmtextid |      1 | Using where; Using index; Not exists |
+----+-------------+--------+-------+---------------+----------+---------+-------------------------+--------+--------------------------------------+
2 rows in set (0.21 sec)
Code:
load averages: 1.83, 3.85, 4.71 mysqld 5.0.95-log up 2 day(s), 12:50 hrs
510 threads: 509 running, 0 cached. Queries/slow: 829/2 Cache Hit: 99.65%
Opened tables: 0  RRN: 91.4K  TLW: 2.9K  SFJ: 0  SMP: 0  QPS: 0

ID       USER     HOST             DB           TIME   COMMAND STATE        INFO
1135964  dbuser  localhost        userdb      726    Query   Sending data SELECT pmtext.pmtextid FROM vb3_pmtext AS pmtext LEFT JOIN vb3_pm AS pm USING(pmtextid) WHERE pm.pmid IS NULL
tarasus добавил 08.05.2015 в 10:45
В развитие темы и в качестве отчёта.
Систему обновили до крайнего релиза в линейке.
Мускль - 5.6.
Пых - 5.4
Конверт таблиц в InnoDB, построение полнотекстового индекса. Форум работает. В очереди запросов ничего не задерживается, своп вободен, диски заняты на 1%, выполняя около 200 операций/сек
В общем как-то так.

Last edited by tarasus : 05-08-2015 at 11:45 AM. Reason: Добавлено сообщение
 
Old  
AleX
vBManiac
 
AleX's Avatar
Default 0

@tarasus, придётся ещё форум обновить (до 3.8.8) или исправлять ошибки (диприкейты) ручками.
 
Old  
tarasus
Простоузер
Default 2

@AleX,
Ошибки исправили, пых допилили до нужного поведения, это уже сделано. Поведать хочу о другом моменте.
Основная проблема, не позволявшая конвертировать медленный MyISAM в более быстрый InnoDB, была в возможности MyISAM создавать полнотекстовый индекс, который использовался в нескольких таблицах. например, в таблице vb3_post. В InnoDB возможность создания полнотекстового индекса появилась, как я уже упоминал, в Mysql версии 5.6. Таблицы были сконвертированы, индекс _как_бы_ создался, форум заработал. НО при попытке осуществить поиск по тексту темы выпадала ошибка БД (к сожалению, не успел сделать скрин _до_ того, как её вылечил), вкратце звучавшая как "невозможно выполнить запрос" "...SELECT postid, post.dateline USE INDEX (threadid)..."
Врукопашную запрос выполнялся без проблем, но при ручном запросе параметр "USE INDEX" не употреблялся.
Задумано - сделано.
Найден файл search.php, в нём два вхождения значения переменной $userid_index = "USE INDEX (threadid)";
дабы исключить из запросной строки явное указание на использование индекса комментируем обе строки двойным слэшем.
При попытке поиска по тексту темы результат не заставляет себя ждать - моментальное нахождение нужного текста.

Надеюсь будет кому-то полезным.
 
Old  
Luvilla
Блондинка с электро......
 
Luvilla's Avatar
Default 1

Quote:
Originally Posted by tarasus View Post
к сожалению, не успел сделать скрин _до_ того, как её вылечил
а на почту ошибки не приходят...

Quote:
Originally Posted by tarasus View Post
медленный MyISAM в более быстрый InnoDB
это тезис для обсуждения, но отнюдь не истина в последней инстанции
 
Old  
tarasus
Простоузер
Default 0

Quote:
Originally Posted by Luvilla View Post
а на почту ошибки не приходят...
к сожалению, не ко мне. Я там, как бы это сказать.... "неосновной"

Quote:
Originally Posted by Luvilla View Post
это тезис для обсуждения, но отнюдь не истина в последней инстанции
не буду спорить, ибо я в б0льшей части - "системщик", т.е. поставить/настроить сервер, дать среду, права, настроить фаерволл, днс, etc,etc - это моё; а выбор табличного пространства БД или движка, который на этом всём будет крутиться - для меня пока не такой простой вопрос. Но я постепенно обучаюсь Соответственно в процессе "обучения" приходится оперировать определёнными категориями, ну и верить на слово людям, которые достигли многого в создании разных информационных ресурсов.
ЗЫ: я тут думал, что у меня таблица ibdata1 большая - занимает чуть менее 11 гигов. При наличии 16 гиг оперативки, рассуждал я, если эта база вся всосётся в память, а это весьма вероятно, свободной памяти останется немного и, возможно, оттого ввод/вывод притормаживает. Но когда товарищ показал мне на впске с 12ю гигами памяти свою БД, в которой ibdata1 весит 160 гигов..... Я понял, что моя база - это "песочница"
Но это по-большому счёту лирика.
ЗЫ2: всегда интересно послушать мнение знающих людей. Возможно эта информация поможет в дальнейшем
 
 

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off




All times are GMT +4. The time now is 01:25 AM.


Powered by vBulletin® Version Anime Edition
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.