Здравствуйте!Начальник IT-отдела принял решение хранить все сессии битрикса в БД. Отговорить не удалось. Но сайт теперь работает еле-еле.
Таблица с сессиями весит 200-500 мегабайт. Посещаемость сайта в среднем 5000 в день.Периодически нагрузка на mysql взмывает до 500 процентов.
На сервере 16 гигов оперативки и 8 ядер. Тип хранилища InnoDB.
Вид таблицы: id, access_time, data . Стоит primary index по id.Кто знает, что можно подкрутить, чтобы БД так не висла?
> Кто знает, что можно подкрутить, чтобы БД так не висла?Начальнику уши
>> Кто знает, что можно подкрутить, чтобы БД так не висла?
> Начальнику ушиА если серьезно, то использовать таблицы Memory
>>> Кто знает, что можно подкрутить, чтобы БД так не висла?
>> Начальнику уши
> А если серьезно, то использовать таблицы MemoryТам надо чтобы сессии не удалялись после ребута, и хранить сессии с авторизацией нужно год (только не смейтесь).
>>>> Кто знает, что можно подкрутить, чтобы БД так не висла?
>>> Начальнику уши
>> А если серьезно, то использовать таблицы Memory
> Там надо чтобы сессии не удалялись после ребута, и хранить сессии с
> авторизацией нужно год (только не смейтесь).Прикрутить костыль с сохранением дампа при завершении работы и восстановлением при загрузке.
На случай сбоя снимать дополнительно по крону.
>>>>> Кто знает, что можно подкрутить, чтобы БД так не висла?
>>>> Начальнику уши
>>> А если серьезно, то использовать таблицы Memory
>> Там надо чтобы сессии не удалялись после ребута, и хранить сессии с
>> авторизацией нужно год (только не смейтесь).
> Прикрутить костыль с сохранением дампа при завершении работы и восстановлением при загрузке.
> На случай сбоя снимать дополнительно по крону.Да, похоже, что первый вариант наиболее мне близок.
>>>>> Кто знает, что можно подкрутить, чтобы БД так не висла?
>>>> Начальнику уши
>>> А если серьезно, то использовать таблицы Memory
>> Там надо чтобы сессии не удалялись после ребута, и хранить сессии с
>> авторизацией нужно год (только не смейтесь).
> Прикрутить костыль с сохранением дампа при завершении работы и восстановлением при загрузке.
> На случай сбоя снимать дополнительно по крону.не на случай сбоя а по крону снимать и перекладывать в обычную таблицу на диске с insert or update с удалением в таблице памяти ну и триггер на остановку с таким же действием.
я бы в эту сторону крутил.
>[оверквотинг удален]
>>>>> Начальнику уши
>>>> А если серьезно, то использовать таблицы Memory
>>> Там надо чтобы сессии не удалялись после ребута, и хранить сессии с
>>> авторизацией нужно год (только не смейтесь).
>> Прикрутить костыль с сохранением дампа при завершении работы и восстановлением при загрузке.
>> На случай сбоя снимать дополнительно по крону.
> не на случай сбоя а по крону снимать и перекладывать в обычную
> таблицу на диске с insert or update с удалением в таблице
> памяти ну и триггер на остановку с таким же действием.
> я бы в эту сторону крутил.Это невероятные костыли. Мне бы InnoDB потюнинговать... Может есть какие опции, чтобы быстро работать с UPDATE WHERE по большим таблицам...
>[оверквотинг удален]
>>>> Там надо чтобы сессии не удалялись после ребута, и хранить сессии с
>>>> авторизацией нужно год (только не смейтесь).
>>> Прикрутить костыль с сохранением дампа при завершении работы и восстановлением при загрузке.
>>> На случай сбоя снимать дополнительно по крону.
>> не на случай сбоя а по крону снимать и перекладывать в обычную
>> таблицу на диске с insert or update с удалением в таблице
>> памяти ну и триггер на остановку с таким же действием.
>> я бы в эту сторону крутил.
> Это невероятные костыли. Мне бы InnoDB потюнинговать... Может есть какие опции, чтобы
> быстро работать с UPDATE WHERE по большим таблицам...оптимизировать запросы и построить нужные для их работы индексы.
> Может есть какие опции, чтобы быстро работать с UPDATE WHERE по большим таблицам...1. построить индексы
2. оптимизировать запросы
3. увеличить размеры кешей мускля
4. пересесть с иннодб на муисам
5. пересесть на RAM-drive
>> Может есть какие опции, чтобы быстро работать с UPDATE WHERE по большим таблицам...
> 1. построить индексы
> 2. оптимизировать запросы
> 3. увеличить размеры кешей мускляя бы сказал оттюнить нужные кеши.
> 4. пересесть с иннодб на муисам
спорно...
> 5. пересесть на RAM-drive
спорно...
>> 4. пересесть с иннодб на муисам
> спорно...На простых длинных таблицах без внешних ключей, и при достаточном ОЗУ, чтобы закешить индекс целиком - муисам быстрее
>> 5. пересесть на RAM-drive
> спорно...Смотря что понимать под рам-драйвом. Для меня это вот такое:
http://arstechnica.adultjohn.info/hardware/news/2009/01/ans-...
>>> 4. пересесть с иннодб на муисам
>> спорно...
> На простых длинных таблицах без внешних ключей, и при достаточном ОЗУ, чтобы
> закешить индекс целиком - муисам быстрееНо ведь не известна даже структура БД, для того чтобы давать такие однозначные ответы. Сейчас например Вы ввели ограничение к своему совету "таблица без внешних ключей".
К тому еще от автора: "Мне бы InnoDB потюнинговать..."...
Слабо представляю надобность использования движка InnoDB без внешних ключей.Я не говорю, что Ваш ответ неверен. Просто нет нужных данных для анализа в исходном вопросе, чтобы дать однозначныый ответ.
>>> 5. пересесть на RAM-drive
>> спорно...
> Смотря что понимать под рам-драйвом. Для меня это вот такое:
> http://arstechnica.adultjohn.info/hardware/news/2009/01/ans-...Спорно, потому что дорого. Бюджет конторы автор темы тоже не оглашал.
>>> 4. пересесть с иннодб на муисам
>> спорно...
> На простых длинных таблицах без внешних ключей, и при достаточном ОЗУ, чтобы
> закешить индекс целиком - муисам быстрееЯ не говорю, что Ваш ответ неверен. Просто нет нужных данных для анализа в исходном вопросе, чтобы дать однозначныый ответ.
Ведь не известна даже структура БД, для того чтобы давать такие однозначные ответы. Сейчас например Вы ввели ограничение к своему совету "таблица без внешних ключей".
К тому еще от автора: "Мне бы InnoDB потюнинговать..."...
Слабо представляю надобность использования движка InnoDB без внешних ключей.>>> 5. пересесть на RAM-drive
>> спорно...
> Смотря что понимать под рам-драйвом. Для меня это вот такое:
> http://arstechnica.adultjohn.info/hardware/news/2009/01/ans-...Спорно, потому что дорого. Бюджет конторы автор темы тоже не оглашал.
К тому же Вами не раскрыта тема, как переезд (со значительными затратами) с одного железа на другое поможет в решении заданного вопроса.
PS
подразумевая нормальную настройку сервиса MySQL на сервере мои рекомендации такие:
- оптимизация запросов (для мускул конкретно: исключение OR выражений - булева алгебра рулит)
- постройка и оптимизация индексов для запосов: постройка нужных/удаление_ненужных (читать как Мускул с индексами работает и вообще понять логику работы индексов)
- последняя линия обороны - использование VIEW, временных таблиц и ОЗУ-движков
- после этого - только железо как в песне: все выше и выше и выше...PSS
- процедуркой все insert|delete|edit делать и отключать индексы на время (угроза целостности БД, но может быть использовано в спец. случаях)
- еще раз настоятельно рекомендую прочитать/понять уровень изоляции транзакций (ибо это подразумевает блокировку share-ресурсов).
> Слабо представляю надобность использования движка InnoDB без внешних ключей.Не стоит исключать возможность создания таблиц иннодб просто по умолчанию. Либо по незнанию.
> К тому же Вами не раскрыта тема, как переезд (со значительными затратами)
> с одного железа на другое поможет в решении заданного вопроса.Ну, как бы, увеличение иопсов с 400 (для сказей 15 крпм) до полумиллиона весьма благотворно влияет на скорость выполнения запросов. Потому что боттлнеком мускля является именно диск, причем не по скорости чтения/записи, а по иопсам.
> исключение OR выражений - булева алгебра рулит
И как прикажете исключать OR из запросов? Что-то я сомневаюсь, что юнион двух селектов эффективнее одного селекта с логическим "или".
> - постройка и оптимизация индексов для запросов
База без нужных индексов - не база :)
> - последняя линия обороны - использование VIEW, временных таблиц и ОЗУ-движковПро представления забудьте. Никакого выигрыша по скорострельности они не дают, реализуются они подзапросами, и задача их совершенно другая - ограничение прав доступа и повышение понимабельности структуры данных человеком. Производительность на вьюшках в лучшем случае - не ниже.
Движок мускля сам создаст все нужные временные таблицы для запроса. Если монолитный запрос тормозит, а два запроса, общающиеся через временную таблицу, не тормозят, значит монолитный запрос кривой.
ОЗУ-движки - вполне хорошо, когда железо позволяет насовать достаточно планок памяти. И когда есть достаточно мощный УПС, который продержит систему онлайн, пока она сливает из МЕМ-таблицы на диск. Но в большинстве случаев отдельное устройство со своими слотами под ДДР, со своей батареей и собственным, монопольно используемым накопителем оказывается существенно дешевле.
> процедуркой все insert|delete|edit делать
В мускле это называется UPDATE.
>> Слабо представляю надобность использования движка InnoDB без внешних ключей.
> Не стоит исключать возможность создания таблиц иннодб просто по умолчанию. Либо по
> незнанию.давайте не будем бредить на эту тему.
>> К тому же Вами не раскрыта тема, как переезд (со значительными затратами)
>> с одного железа на другое поможет в решении заданного вопроса.
> Ну, как бы, увеличение иопсов с 400 (для сказей 15 крпм) до
> полумиллиона весьма благотворно влияет на скорость выполнения запросов. Потому что боттлнеком
> мускля является именно диск, причем не по скорости чтения/записи, а по
> иопсам.тем не менее тема применения SSD именно для этой задачи до сих пор не раскрыта. и не будет/не_может_быть раскрыта - нет достоверных данных данных для таких выкладок.
>> исключение OR выражений - булева алгебра рулит
> И как прикажете исключать OR из запросов? Что-то я сомневаюсь, что юнион
> двух селектов эффективнее одного селекта с логическим "или".union - это не OR в where выражении. Вам видисо стоит вообще про SQL почитать. Про конкретный движок ДБ пока помолчу.
>> - постройка и оптимизация индексов для запросов
> База без нужных индексов - не база :)
>> - последняя линия обороны - использование VIEW, временных таблиц и ОЗУ-движков
> Про представления забудьте. Никакого выигрыша по скорострельности они не дают, реализуются
> они подзапросами, и задача их совершенно другая - ограничение прав доступа
> и повышение понимабельности структуры данных человеком. Производительность на вьюшках
> в лучшем случае - не ниже.вот именно - чтобы ручки-недоручки спрашивали VIEW, которые оптимизированы на работы с индексами. К сожалению это только в простейшем случае возможно - ибо любая выборка по VIEW индексы уже не использует (давно правда этим не интерисовался - может уже и не так - возможность реализации анализировать не хочу)
> Движок мускля сам создаст все нужные временные таблицы для запроса. Если монолитный
> запрос тормозит, а два запроса, общающиеся через временную таблицу, не тормозят,
> значит монолитный запрос кривой.угу. или надо учитывать блокировки, которые один сложный запрос делает или различных два подряд. и управлять уровнями изоляции транзакций. чтобы результат в конце концов был одним и тем же.
> ОЗУ-движки - вполне хорошо, когда железо позволяет насовать достаточно планок памяти. И
> когда есть достаточно мощный УПС, который продержит систему онлайн, пока она
> сливает из МЕМ-таблицы на диск. Но в большинстве случаев отдельное устройство
> со своими слотами под ДДР, со своей батареей и собственным, монопольно
> используемым накопителем оказывается существенно дешевле.
>> процедуркой все insert|delete|edit делать
> В мускле это называется UPDATE.спасибо Кеп. Даже в SQL-92 (уже довольно старом по нынешним меркам, но рекомендую Вам к прочтению) это именно так, как Вы сказали и называется.
>[оверквотинг удален]
>>>> Там надо чтобы сессии не удалялись после ребута, и хранить сессии с
>>>> авторизацией нужно год (только не смейтесь).
>>> Прикрутить костыль с сохранением дампа при завершении работы и восстановлением при загрузке.
>>> На случай сбоя снимать дополнительно по крону.
>> не на случай сбоя а по крону снимать и перекладывать в обычную
>> таблицу на диске с insert or update с удалением в таблице
>> памяти ну и триггер на остановку с таким же действием.
>> я бы в эту сторону крутил.
> Это невероятные костыли. Мне бы InnoDB потюнинговать... Может есть какие опции, чтобы
> быстро работать с UPDATE WHERE по большим таблицам...ну почитайте еще на счет уровня изоляции транзакций. м/б чем-то Вам поможет.
PS
чудес на свете не бывает.