Добрый день.
Не могу сказать что oscar3 проблемный сервер, ну то есть, да конечно есть проблемные сервера и не всегда получается быстро исправить ситуацию. Просто банальный пример - диски начали умирать, надо все заменить. Это приводит к деградации raid - и падению производительности, продолжаться это может 5 дней.
В любом случае напишите пожалуйста мне на почту alexey собакен beget.ru, постараюсь разобраться в ситуации.
Мы используем не стандартный хандлер redis - а свой. В случае если редис не доступен сессии работают с файлами. Так же добавили модуль который пишет в лог где, на какой строке, какой URL вызывался и сколько времени была блокировка. Не могу сказать, что это было сложно сделать - но в момент внедрения проблем мы получили не мало.
теперь как устроенно разделение. У каждого пользователя в docker работает свой экземпляр redis со своим настройками памяти, конфигами. Работает от имени суб-пользователя привязанного к основному пользователю (для сбора статистики стандартными средствами)
далее в iptables прописываем правила, их для каждого пользователя может быть много
Там два правила для локальных подключений и для внешних - это можно все настроить с панели управления. И получается, фактически когда пользователь стучится на 127.0.0.1:6379 его запрос перенаправляется внутрь контейнера, другие запросы внутрь контейнера попасть не могут.
Это позволяет поднимать приватные экземпляры redis, memcache, sphinx, mysql, postgress - да в принципе всего чего угодно в рамках виртуального хостинга.
Если честно я с HostCMS не разу не работал, в код не лазил, подсказать по этому вопросу не могу. Блокировки - это не к хостингу это больше к PHP. Только мы решили сообщать об этой проблеме, так как иногда это помогает.---------- Добавлено 27.10.2017 в 04:59 ----------пс. надеюсь пользователь aalangow не сильно обидеться что я указал его логин в примере...
Пожалуй я еще раз скопирую сообщение сюда:
-------------------------------
По блокировке сессий, откровенно говоря это функционал которым я горжусь, так как такого больше не у кого нету. Суть проблемы в следующем: делаем скрипт который открывает сессию и делает там sleep(100), открываем его в двух вкладках и внимательно смотрим как долго у нас открывается вторая вкладка.
При этом так называемые "тормоза сайта" не будут связаны не с мощностью сервера, не с потребляемыми ресурсами или лимитами. В свое время мы написали небольшое расширение для php, которое отлавливает эту ситуацию и сделали микросервис Redis в котором можно хранить сессии. Нельзя сказать, что решение отличное - так как возможны ситуации с неконсистентностью данных, то есть когда один процесс меняет данные пока второй работает с этими данными, но это бывает редко и в подавляющем ряде случаев не вызывает проблем.
Это не как не связанно с нагрузкой на сайт и даже если Вы перенесете сайт от нас - проблема останется, только об ее существовании Вам не кто не скажет.
Ниже ссылки на которых можно прочесть о проблеме:
https://dev.1c-bitrix.ru/learning/co...LESSON_ID=2687
https://beget.com/ru/articles/redis_session
http://php.net/manual/ru/session.examples.basic.php
https://habrahabr.ru/company/bitrix/blog/179803/
Если Bitrix пишет о проблеме на habre - почему бы нам не уведомить клиентов о том, что такая проблема есть и не решить ее ? Наверное это вопрос из серии - зачем предупреждать пользователей о вирусах на их сайте ? Или о том, что запросы к БД блокируют друг друга и сайт открывается по 10 секунд ?
Я не могу сказать, что Redis для хранения сессий пользуется большой популярностью - но для тех кому он действительно нужен это очень хорошая фича.
Хорошая позиция, после единственного ответа от человека который имеет отношение к Beget - тишина... Хоть прокомментируйте может мы что-то можем сделать лучше ?
Дочитал до 4 страницы - дальше, особого смысла читать нету. Я являюсь соучредителем Beget, раньше писал на этом форуме, потом мои посты удалили с обоснованием, что по правилам надо писать в отдельной теме, последние полгода сюда не заглядывал.
Это не как не связанно с нагрузкой на сайт и даже если Вы перенесете сайт от нас - проблема останется (другое дело, что для Вас она не критична), только об ее существовании Вам не кто не скажет.
https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=38&LESSON_ID=2687
Если Bitrix пишет о проблеме на habre - почему бы нам не уведомить клиентов о том, что такая проблема есть и не решить ее ? Наверное это вопрос из серии - зачем предупреждать пользователей о вирусах на их сайте ? Или о том что запросы к БД блокируют друг друга и сайт открывается по 10 секунд ?
Если подвести итог: лучше пускай про нас напишет один 1 из 250000 клиентов, что мы разводим "маркейтинговую хренотень" чем у 1000 клиентов сайт будет работать медленнее и они напишут нам в техническую поддержку... Я приношу извинения если данное сообщение доставило неудобство - напишите мне (alexey песик beget.ru) Ваш логин и больше не какие уведомления подобного рода Вас беспокоить не будут.---------- Добавлено 28.09.2017 в 23:51 ----------
Опять же не могу не прокомментировать...
cp - это как раз 3 столбец в выводе этой команды, что бы более подробно разобраться читаем инструкцию https://www.opennet.ru/man.shtml?topic=sa&category=8&russian=2.
Опция -m
Если дать точно определение из инструкции "sum of system and user time in cpu seconds " - суммарное потраченное время процессора user и kernel space на обработку процессов пользователя, получаемая стандартными средствами ядра linux.
Но наверное, многие читатели этого форума спросят - почему же этого попугая (CP) называю абстрактным. Ответ на этот вопрос достаточно простой - если у Вас сервер на базе процессора Xeon 5520 с hdd и 12 гигабайтами оперативной памяти - cp будет больше, чем когда у Вас Xeon E5-2699v4 с 8 SSD Intel 37XX и 512 гигабайтами памяти. Это время учитывает операции ввода/вывода - и на медленных системах это может быть существенно. Так же нужно понимать что чистота, архитектура у процессоров разная и сравнивать данного попугая можно только с аналогичным оборудованием.
Наверное я бы еще рассказал про то какое оборудование мы ставим, но боюсь что опять все мои сообщения удалят =)
Странно, я думал пингую сайт хостинга "ping h4s.ru", а оказалось Вашу VPS =).
пс. В любой случае такие сообщения и реакция подобная моей, к несчастью, появляются на данном форуме с завидной регулярностью. То же самой относится и к самой теме топика...
Топик достаточно приятный.
Пожалуй, прокомментирую последнее сообщение =)))
Я думаю этот разговор не имеет смысла, как минимум из-за разницы в знаниях.
Но я все таки этот идиотизм прокомментирую: формулировка сама по себе - "пробежался по серверам". Отлично и на глаз вы заметите блокировку от 0.1 до 2 секунд ? (Даже top медленней обновляется). Вот если Вы добавите в php логирование и уже потом посмотрите логи - можно будет продолжить разговор.
В отличии от других хостингов - видимо и Вашего мы мониторим эту ситуацию. Если бы Вы чуть более подробно прочитали об этой проблеме, то поняли, это фундаментальный недостаток PHP при хранении сессий в файлах.
Например блокировка на ajax запрос в 0,2 секунды - вроде не критична, но не приятна. А если таких запросов 10000 ?
Добавили в панель уведомление о блокировке сессий в PHP, а заодно собрали статистику о простое сайтов из-за блокировки сессий. Во время блокировки сайты не отвечают, ожидая, пока файл сессии освободится.
количество времени, которое сайты на нашем хостинге были заблокированы из-за сессий в PHP
01.04 - 2233 часов
02.04 - 1232 часа
03.04 - 1332 часа
04.04 - 1672 часа
05.04 - 1740 часов
06.04 - 1514 часов
07.04 - 1453 часа
08.04 - 1598 часов
09.04 - 1289 часов
10.04 - 1517 часов
В среднем сайты не отвечали 1562 часа в день.
Максимальное суммарное время блокировки для одного ресурса составило 2468 часов за 3 дня (к сожалению, название ресурса привести не можем). 2468 часов сайт не отвечал за 3 дня Карл =) !!!
Количество доменов с блокировками за последние три дня 4358.
---------- Добавлено 11.04.2017 в 19:02 ----------пс. кто нибудь знает как указать размер изображения ? =)
