Внезапное расширение БД

[Набоков]

Извините, если написал не туда, но поиск ничего не посоветовал.
SMF: 1.1.16
Есть ВПС, с 20 Гб дискового пространства. Свободно 6,1 Гб
Общее место БД smf 7,1 Гб. Из них smf_log_search_words  4.6 GB
Сами файлы ВПС+ ещё крохотная БД другого движка занимает место округленно 7Гб
Но уже третий раз за месяц происходит один и то же сбой: при 6,1 Гб свободного места вдруг диск переполняется, сайт и ВПС зависают, и так продолжается примерно 40 минут, после чего бьется таблица smf_log_search_words, освобождая 9Гб места. Я её восстанавливаю, и всё возвращается к исходной позиции, - 6,1 Гб свободного места.
По моей просьбе хостер представил лог на момент, когда я не могу войти в ВПС, и понаблюдать происходящее. Он пишет, что общий объём smf_log_search_words в этот момент     
1.8G    smf_log_search_words.MYD
2.9G    smf_log_search_words.MYI
1.8G    smf_log_search_words.TMD
То есть не 4.6 GB, а 6,5 GB
Вопрос, что происходит?
Хостер говорит, что никаких бэкопирующих, или иных технических записей в этот момент ВПС на свой диск не выполняет, во всём виновата таблица smf, и надо обращаться к разработчикам движка,  который совершает непроизвольный рост:
Текущее состояние дисковой квоты:
Filesystem            Size  Used Avail Use% Mounted on
/dev/simfs             20G   20G     0 100% /
Действительно ли таблица smf_log_search_words совершает время от времени какие-то архивирующие действия, которые требуют дополнительного дискового пространства? Что за расширения MYD, MYI, и TMD, которых не видно в БД ВПС, и почему там вместо 4,6 GB, - 6,5 GB? Не посчитали ли 1.8G дважды? Может быть, из-за какого-то сбоя в прошлом, smf_log_search_words начала вести себя нестандартно, требуя на архивацию дополнительное дисковое пространство? 

[Набоков]

Обычно, когда бьётся smf_log_search_words, сайт работает нормально, но при отправлении сообщений возникает сообщение об ошибке, но, может быть, тут сначала бьётся smf_log_search_words, потом почему-то переполняется диск, потом, почему-то освобождается, и я вижу уже разбитую таблицу, и 9 Гб свободного места?     

[digger®]

Вам просто нужно больше дискового места на сервере при такой базе, или отказаться от выборочного индексирования для поиска (для него и используется smf_log_search_words) если с местом напряженка. Можно сменить индексирование на малоразмерное.
У вас таблица сообщений и таблица индексов для поиска по несколько гигабайт, при таких операциях как оптимизация или восстановление они, конечно, не вмещаются в оперативную память и для них создаются временные таблицы на диске, которые и съедают свободное место.

P.S.
Хостеру бы неплохо прочитать любой букварь про MySQL, чтобы он был в курсе про "непроизвольный рост".

[Набоков]

Вам просто нужно больше дискового места на сервере при такой базе, или отказаться от выборочного индексирования для поиска (для него и используется smf_log_search_words) если с местом напряженка. Можно сменить индексирование на малоразмерное.
У вас таблица сообщений и таблица индексов для поиска по несколько гигабайт, при таких операциях как оптимизация или восстановление они, конечно, не вмещаются в оперативную память и для них создаются временные таблицы на диске, которые и съедают свободное место.

То есть 6,1 Гб свободного места в данной ситуации мало?
А сколько надо? Вы исключаете ошибку, возникшую в smf_log_search_words, и приводящую к такому сбою? Где-нибудь можно почитать о всём этом более детально?
Дело ещё в том, что когда я задаю команду на восстановление таблицы smf_log_search_words, она проходит без сбоев, хотя и требует минут 3-5.   

[Mr. Anviss]

Набоков
Это лишь предположение.
Файл smf_log_search_words.tmd - временный файл который образуется в момент компресии таблицы, а также может создаваться при других операциях с базой (например оптимизация).
Т.к. у вас в момент компресии не хватает места на диске то происходит крах таблицы smf_log_search_words и этот файл остается на диске, а не удаляется как если бы операция компрессии завершилась успешно.
Согласен с digger про хостера.

[digger®]

То есть 6,1 Гб свободного места в данной ситуации мало?

Возможно у вас в проблемный момент, что-то еще переполняет файловую систему на сервере, вследствие чего и бьется smf_log_search_words.
Когда хостер откроет для себя существование временных таблиц в MySQL, пускай смотрит чем еще забит диск в этот момент.

[Набоков]

Набоков
Файл smf_log_search_words.tmd - временный файл который образуется в момент компресии таблицы.

Цикличность компрессии задаётся на сервере?

Т.к. у вас в момент компресии не хватает места на диске то происходит крах таблицы  smf_log_search_words и этот файл остается на диске, а не удаляется как если бы операция компрессии завершилась успешно.

Но smf_log_search_words.tmd занимает всего 1.8G, а свободного места 6,1 G. Должно хватать с большим запасом.   

Можно сменить индексирование на малоразмерное.

Как это сделать? "Выборочное индексирование" сменить на "Полнотекстовое индексирование?"

[digger®]

Цикличность компрессии задаётся на сервере?

Временный файл может создаваться в любой момент при необходимости перестройки индексов таблицы.
Посмотрите в админке "Диспетчер задач - Оптимизация базы данных", не совпадает ли по времени с проблемными моментами.

Но smf_log_search_words.tmd занимает всего 1.8G, а свободного места 6,1 G. Должно хватать с большим запасом.

Возможно у вас в проблемный момент, что-то еще переполняет файловую систему на сервере, вследствие чего и бьется smf_log_search_words.Когда хостер откроет для себя существование временных таблиц в MySQL, пускай смотрит чем еще забит диск в этот момент.

Как это сделать? "Выборочное индексирование" сменить на "Полнотекстовое индексирование?"

У вас полнотекстовое раздует таблицу сообщений, а она у вас тоже не маленькая, видимо. Попробуйте сначала удалить индексы в "Выборочное индексирование" и создать их заново, выбрав малоразмерное индексирование.

[Набоков]

Посмотрите в админке "Диспетчер задач - Оптимизация базы данных", не совпадает ли по времени с проблемными моментами.

Это на ВПС, или в SMF? Что-то не соображу.

Попробуйте сначала удалить индексы в "Выборочное индексирование" и создать их заново, выбрав малоразмерное индексирование.

А там же, по-моему, кроме выбора какой тип (Полнотекстовое индексирование, или Выборочное индексирование) других возможнстей нет?

[Mr. Anviss]

Это на ВПС, или в SMF? Что-то не соображу.

SMF 2

[Набоков]

SMF

В SMF: 1.1.16 это есть?

[Набоков]

SMF

В SMF: 1.1.16 это есть?

[Mr. Anviss]

про 1.1.16 не скажу

[Набоков]

про 1.1.16 не скажу

Мне там не удалось найти что-либо похожее.

Удалить smf_log_search_words, конечно, можно, как можно и ограничить пользование поиском, но прежде хотелось бы точно увериться, что после удаления проблема не останется, только уже без таблицы smf_log_search_words. 

[Набоков]

Когда хостер откроет для себя существование временных таблиц в MySQL, пускай смотрит чем еще забит диск в этот момент.

Так хостер и признавал это с самого начала, сообщив мне, что видит
1.8G    smf_log_search_words.MYD
2.9G    smf_log_search_words.MYI
1.8G    smf_log_search_words.TMD
Вряд ли где-то есть хостер, который будет брать на себя обязанности отвечать за работу движков, расположенных у него на серверах. Это противоречит договору. Чтобы обратиться к нему с просьбой, или претензией, я должен указать на недочёты в работе его оборудования, или ПО. Для изыскания такой формулировки я сюда и пришёл. Не могу же я ему сказать, давай, мол, ищи, чего это у меня там в SMF работает неправильно.
      Можно ли узнать что за расширения MYD, и MYI? Если предположить, что во время компрессии образуется не один файл TMD, а три (TMD, MYD, MYI), или хотя бы два, то 6,1Гб вполне можно переполнить. Вся smf_log_search_words занимает 4.6 GB. Если она в момент компрессии утраивается, вот и получаем переполнение 6,1 Гб.   

[Mr. Anviss]

MYD MYI FRM - для каждой таблицы в базе типа  myisam создаются 3 файла с такими расширениями.
Так а про хостера вы сами написали что он сказал следующее: Хостер говорит, что никаких бэкопирующих, или иных технических записей в этот момент ВПС на свой диск не выполняет, во всём виновата таблица smf, и надо обращаться к разработчикам движка. digger сказал же, и я согласен с ним, что вам не хватает места на диске и при чем тогда здесь двиг smf?

[karavan]

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

[Набоков]

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

Какой у вас объём БД smf? Сколько в среднем посетителей? Если два или более посетителей одновременно задают поиск, сервер не вешается?

[karavan]

БД 83 Мб. Пользователей (зарегистрированных) заходит 100-120 в сутки, одновременно 20-30-40. Среднее количество сообщений в день:   261.17
Среднее количество просмотров в день:   10891.52
Сервер вроде не вешается.

[Набоков]

БД 83 Мб. Пользователей (зарегистрированных) заходит 100-120 в сутки, одновременно 20-30-40. Среднее количество сообщений в день:   261.17
Среднее количество просмотров в день:   10891.52
Сервер вроде не вешается.

Ну, эти показатели всё равно, что ничего.

[karavan]

) что, так мало? я думал 260 сообщений в день это много...

[digger®]

) что, так мало? я думал 260 сообщений в день это много...

Когда в базе пара миллионов сообщений наберется, тогда поговорим о поиске без индексов

[karavan]

Ясно у меня пока 125 тысяч сообщений.

[Mavn]

если у вас свой впс то не проще ли перенести поиск на сфинкса?

[Набоков]

если у вас свой впс то не проще ли перенести поиск на сфинкса?

А что это такое?

[GeorG]

Релевантный поисковик. Вот например тут, можно почитать по на стройки для smf.

[Mavn]

тогда уж лучше:
1. http://sphinxsearch.com/
2. зайти на офф сайт. подать запрос в группу Big Forum Operator
3. В теме скачать апи для сфинкса и установить на форум.

ПС там довольно просто все сделать

[Набоков]

Спасибо.

[Набоков]

тогда уж лучше:
1. http://sphinxsearch.com/
2. зайти на офф сайт. подать запрос в группу Big Forum Operator
3. В теме скачать апи для сфинкса и установить на форум.

ПС там довольно просто все сделать

Скажите, а работа этого Сфинкса требует создания индексной базы, и насколько большой? Не хотелось бы сначала установить сфинкс, потом нашлепать за пару недель базу, а потом её удалить из-за неприемлемой величины. Если эта база будет даже хотя бы вдвое меньше прежней, она всё равно будет слишком  большой. (3,5 миллиона сообщений это много.)

[digger®]

Скажите, а работа этого Сфинкса требует создания индексной базы, и насколько большой? Не хотелось бы сначала установить сфинкс, потом нашлепать за пару недель базу, а потом её удалить из-за неприемлемой величины. Если эта база будет даже хотя бы вдвое меньше прежней, она всё равно будет слишком  большой. (3,5 миллиона сообщений это много.)

На 2.5 миллиона сообщений форума индексная база сфинкса 850 мегабайт.

[Набоков]

На 2.5 миллиона сообщений форума индексная база сфинкса 850 мегабайт.

Спасибо.
То есть для моих 3,5 миллиона она составит где-то 1,19Гб, что более чем в четыре раза меньше 5Гб стандартной индексной таблицы SMF для моих 3,5 млин.

[Slavegirl]

У меня тоже 1,3 млн. сообщений, и партнер также предложил на днях подключить сфинкс. Подскажите, пожалуйста, сфинкс повлияет только на функцию поиска по форуму, или абсолютно на все запросы к БД, например, при сортировке тем в разделе? Не знакома с ним вообще просто, только по наслышке.

[Набоков]

На 2.5 миллиона сообщений форума индексная база сфинкса 850 мегабайт.

В Сфинксе же два типа хранилища? БД, и файлы.
Ваш пример относится к первому или второму?

[digger®]

В Сфинксе же два типа хранилища? БД, и файлы.
Ваш пример относится к первому или второму?

В сфинксе одно хранилище - своя индексная структура, которая хранится в файлах, как и любая другая БД.

[Набоков]

Скажите, а насколько представителен поиск с помощью Сфинкса? База поисковых индексов SMF в два-три раза больше базы самих сообщений, но она не даёт и половины тех ответов, которые можно получить при поиске без индексной базы. То есть такая огромная база ищет существенно хуже. А база Сфинкса, которая по сравнению с SMF-овской крохи, наверное, ещё менее представительна?   

[digger®]

Скажите, а насколько представителен поиск с помощью Сфинкса? База поисковых индексов SMF в два-три раза больше базы самих сообщений, но она не даёт и половины тех ответов, которые можно получить при поиске без индексной базы. То есть такая огромная база ищет существенно хуже. А база Сфинкса, которая по сравнению с SMF-овской крохи, наверное, ещё менее представительна?   

Ищет хоть по одной букве. Поддерживается стемминг и подключение внешних морфологических движков.
Полная индексация 2.5 миллионов сообщений производится минут за 20.

[Набоков]

Ищет хоть по одной букве.

Ну, по одной букве-то он ищет, но не значит, найдёт. Я проводил эксперимент: брал одного и того же пользователя с большим (10 000 - 20 000 сообщений) и проверял выдачу одного и того же специфического слова или термина до и после индексации SMF стандартной базой индексов. В результате выдача после индексации падала раз в десять, а это, ещё раз повторяю, просто охрененно большая база индексов.
Мне интересно, Сфинкс как бы совершает свои чудеса благодаря какому-то сверх эффективному алгоритму в сравнении со стандартной базой поисковых индексов SMF?   

Полная индексация 2.5 миллионов сообщений производится минут за 20.

Просто разрыв мозга! У меня (правда при работающем сайте) на индексацию стандартной базы (4 Гб) уходила где-то неделя непрерывного шлёпания индексов. (И, кстати, стандартная база поисковых индексов SMF часто ломается, а поломавшись, блокирует отправку любого сообщения, пока её не починишь.)   

[digger®]

Ну, по одной букве-то он ищет, но не значит, найдёт.

Ну, по одной букве смысла особого нет искать. По двум ищет прекрасно - имена объектов типа "A1".

Мне интересно, Сфинкс как бы совершает свои чудеса благодаря какому-то сверх эффективному алгоритму в сравнении со стандартной базой поисковых индексов SMF?   

Сфинкс - это как бы специализированный поисковый движок, а стандартный поиск - это тупой select из mysql базы.

Полная индексация 2.5 миллионов сообщений производится минут за 20.
Просто разрыв мозга! У меня (правда при работающем сайте) на индексацию стандартной базы (4 Гб) уходила где-то неделя непрерывного шлёпания индексов.

Тут да, вне конкуренции. И для стандартного поиска даже нет никакой возможности индексацию из консоли запустить. Больше миллиона - уже полный песец по времени для стандартного индексатора.

Если потребуется - могу оказать оплачиваемую помощь по внедрению Сфинкса. Пишите в личку.

[Slavegirl]

Встряну в Ваш разговор. Я ускоряла стандартную индексацию 2Гб базы данных с помощью iMacros, который каждую секунду нажимал кнопку "Продолжить" (без необходимости ожидать 10 секунд до следующей итерации). За сутки макрос справился.

[digger®]

Встряну в Ваш разговор. Я ускоряла стандартную индексацию 2Гб базы данных с помощью iMacros, который каждую секунду нажимал кнопку "Продолжить" (без необходимости ожидать 10 секунд до следующей итерации). За сутки макрос справился.

Вот это классический костыль - сидя на выделенном сервере, решать задачи браузерным скриптом.
Ну и уж проще было в форумном скрипте исправить интервал этой кнопки.

[Slavegirl]

Хм... digger, Вы единственный здесь, сообщения которого я добавляю в закладки
Привыкла я просто все дела на сайтах автоматизировать с помощью макроса, а о таком простом решении, как отредактировать скрипт на своем собственном сайте не догадалась...

digger, можно Вас попросить написать мне в личку стоимость Вашей работы по подключению Сфинкса на форум, чтобы я могла ориентироваться? Возможно, придется обратиться за помощью. Заранее большое спасибо!

[Набоков]

Эффективность Сфинкса поражает воображение.
Профессионализм digger®-а выше всяких похвал. Рекомендую.

[Серый Лис]

Замечательные рекомендации!
Да, Нужно быть действительно утомленным SMF,  чтобы обладать таким профессионализмом!
digger   +
Спасибо участникам дискуссии