- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Если у вас получается воспроизвести проблему, сделайте отладку кода. Найдите тот участок кода, который вызывает проблему.
Благодарю вас за подробный ответ!
В том то и проблема, что ошибка появляется не систематически, повторить её не получается, так что отладка кода невозможна, в виду непонятности что в нем дает ошибку.
Как так ничего нельзя? Храните страницы в статике и делов-то, когда Мускул лежит, то пользователь даже не знает что он (мускул) лежит.
Далеко не каждый сайт может хранить все в статике. Да и грамотная инвалидация сложный вопрос, когда это блог это одно, а когда это какой то сервис, интернет магазин или еще что то сильно зависещее от динамических данных это совсем другая история.
PS. Если вы можете сложить все в "вечный кеш", почему просто не отрендерите сайт в статику и не выложить настоящей статикой? Вам БД тогда и не нужна будет и нагрузка 0, и ответа от бэкенда не будет и 502 не будет))
---------- Добавлено 02.11.2017 в 23:54 ----------
Благодарю вас за подробный ответ!
В том то и проблема, что ошибка появляется не систематически, повторить её не получается, так что отладка кода невозможна, в виду непонятности что в нем дает ошибку.
Поискать ошибки можно установив свои логи которые перехватывают исключения/ошибки. Например воспользоваться сервисом https://rollbar.com/ он отловит все ваши ошибки и он частично бесплатный (с лимитами).
Но 502 ошибку вы можете не поймать, так как это ошибка когда nginx рвет соединение с бэкендом, а так как это шаред, затормозить сервер может не только ваш акк, если кто то в момент времени загрузил проц, ваш процесс может дольше ожидать процессорного времени, чем может ждать nginx, процесс то в итоге отработает, но nginx уже выкинет 502. Именно по этой причине сервисы разбивают на несколько серверов, фронт отдельно, бэк отдельно, бд отдельно - это все приоритетные процессы и являются сильноконкурирующими за процессор.
---------- Добавлено 03.11.2017 в 00:08 ----------
У меня у товарища аккаунт на бегете есть, сервис специализированный, пристройка к популярной облачной срм, так вот у него в статистике нагрузка на аккаунте была больше 1500% от лимита (не знаю как сейчас), вот такие клиенты и создают видимо 502 ошибки на сайтах других клиентов ))
PS. Не знаю, выгнал ли его еще бегет или нет :))
Но 502 ошибку вы можете не поймать, так как это ошибка когда nginx рвет соединение с бэкендом, а так как это шаред, затормозить сервер может не только ваш акк, если кто то в момент времени загрузил проц, ваш процесс может дольше ожидать процессорного времени, чем может ждать nginx, процесс то в итоге отработает, но nginx уже выкинет 502.
Нет, nginx выкинет 504 Gateway time-out :)
Далеко не каждый сайт может хранить все в статике. Да и грамотная инвалидация сложный вопрос, когда это блог это одно, а когда это какой то сервис, интернет магазин или еще что то сильно зависещее от динамических данных это совсем другая история.
Было дело с ИМ, тоже использовал похожую связку, когда карточки товара были статикой html, на которых иконка корзины AJAX, сама корзина частично AJAXовая и т.д. Всех подробностей уже не помню, лет 10 назад было.
PS. Если вы можете сложить все в "вечный кеш", почему просто не отрендерите сайт в статику и не выложить настоящей статикой?
Возможно я неверно выразился, но сайт по сути отрендерен и сложен в одну папку, в виде множества html страниц.
Поискать ошибки можно установив свои логи которые перехватывают исключения/ошибки. Например воспользоваться сервисом https://rollbar.com/ он отловит все ваши ошибки и он частично бесплатный (с лимитами).
Но 502 ошибку вы можете не поймать, так как это ошибка когда nginx рвет соединение с бэкендом, а так как это шаред, затормозить сервер может не только ваш акк, если кто то в момент времени загрузил проц, ваш процесс может дольше ожидать процессорного времени, чем может ждать nginx, процесс то в итоге отработает, но nginx уже выкинет 502. Именно по этой причине сервисы разбивают на несколько серверов, фронт отдельно, бэк отдельно, бд отдельно - это все приоритетные процессы и являются сильноконкурирующими за процессор.
У меня ещё в этой цепочке участвует мемкешед, но за ссылку на сервис спасибо.
Ну что же, сегодня и я, до сих пор долгое время лояльный клиент Beget, готов внести свою, пожалуй, первую ложку дегтя.
Так что теперь уже никто, наверное, не посмеет усматривать мою возможную в этом вопросе предвзятость :)
Сервер, где находятся сайты одного из клиентов лежит уже более получаса. Подобного никогда не происходило даже близко. Были лишь не столь частые и совсем непродолжительные плановые ночные перезагрузки.
Я понимаю, что лежать могут все, но вместе с тем никакой реакции на происходящее от них до сих пор не последовало.
Кого-то еще задело?
ЗЫ
Спустя 40 минут веб-сервер поднялся, вскоре поднялся и сервер баз данных. Сейчас сайты вновь доступны. Общее время лежки составило 43 минуты, что, как по мне, весьма не мало.
Таким образом, сегодняшний аптайм 94%, месячный пока что - 99,5%.
Посмотрим на их реакцию, которой нет до сих пор (хотя обычно они весьма оперативны), на основе в том числе и которой будем делать дальнейшие выводы.
se43, легли практически наглушняк только что. Саппорт в скайпе отослал в тикеты, тикеты молчат. По второму тикету жду ответ третий час.
se43, легли практически наглушняк только что. Саппорт в скайпе отослал в тикеты, тикеты молчат. По второму тикету жду ответ третий час.
Клиентские сайты на трех разных бегетовских серверах, проверил, вроде работают.
aleksandrbol, от сервера, видимо, зависит. Снова признали свои косяки в тикете, попросил перенести на другой сервер, ибо сил уже нет. Посмотрим, что из этого выйдет.
Сервер, где находятся сайты одного из клиентов лежит уже более получаса. Подобного никогда не происходило даже близко. Были лишь не столь частые и совсем непродолжительные плановые ночные перезагрузки.
Я понимаю, что лежать могут все, но вместе с тем никакой реакции на происходящее от них до сих пор не последовало.
Кого-то еще задело?
ЗЫ
Спустя 40 минут веб-сервер поднялся, вскоре поднялся и сервер баз данных. Сейчас сайты вновь доступны. Общее время лежки составило 43 минуты, что, как по мне, весьма не мало.
Таким образом, сегодняшний аптайм 94%, месячный пока что - 99,5%.
Посмотрим на их реакцию, которой нет до сих пор (хотя обычно они весьма оперативны), на основе в том числе и которой будем делать дальнейшие выводы.
А какая реакция должна была произойти за 40 минут? Танцы с бубном перед тем, как тех. отдел пойдёт править проблему? :)
Или должно быть уведомление на сайте?
Beget умело скрывает даже инфу об оборудовании, на котором предоставляет хостинг, считая нагрузку в CP, то есть в попугаях, а что за попугаи - непонятно и не написано, совсем непонятно сколько это 30 СР много или мало? Може у них устаревший Via C7 :)
---------- Добавлено 06.11.2017 в 21:37 ----------
aleksandrbol, от сервера, видимо, зависит. Снова признали свои косяки в тикете, попросил перенести на другой сервер, ибо сил уже нет. Посмотрим, что из этого выйдет.
Я таки ошибся? Все еще хуже? Сервер VIA C3 1 ГГц 512 МБ 160 ГБ HDD? :)
Не люблю хостинг-провайдеров, которые утаивают информацию о железе, на котором хостят и меряют нагрузку при этом еще и в попугаях. Такие хостинг-провайдеры заслуживают наказания палками.
Beget умело скрывает даже инфу об оборудовании, на котором предоставляет хостинг, считая нагрузку в CP, то есть в попугаях, а что за попугаи - непонятно и не написано, совсем непонятно сколько это 30 СР много или мало? Може у них устаревший Via C7 :)
Так они вроде пишут про объем памяти, про процессор, про общую нагрузку на сервер (именно на сервер, а не на аккаунт), в чем тут сложность?