- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Сотрудничайте с кем-то постоянно. Если нет желания приобретать профильные знания систематически - имеет смысл отдать кому-то сервера на постоянное администрирование.
К сожалению, учитывая мои доходы и цены на администрирование серверов, у меня нет возможности нанять администратора на постоянное администрирование...
Тогда стоит подумать об смене vps на vip хостинг
Тогда стоит подумать об смене vps на vip хостинг
У меня выделенный сервер.
У меня выделенный сервер.
Тем хуже - за железками добрый дядинька не следит...
Цитата:
Сообщение от Logger Посмотреть сообщение
pm заставьте слушать сокет а не tcp
Если ставлю в конфиге nginx:
Цитата:
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/tmp/php-fpm.sock;
то nginx для этого хоста выдает:
Цитата:
502 Bad Gateway
nginx/1.0.14
тогда вам уже надо обращаться за платными услугами
Нет :), оказывается достаточно просто еще дописать одну строчку в конфиг php-fpm. Подсказали тут.
В файле /etc/php5/fpm/pool.d/www.conf
; listen = 127.0.0.1:9000
listen = /tmp/php-fpm.sock
В логе две разные ошибки:
и
Скорее всего ошибки, как то связанны.
Чтобы избавиться от первой ошибки, можно увеличить число процессов(pm.max_children) до 10-100. А также разобраться, почему увеличилась нагрузка(время обработки запроса и/или количество запросов).
По второй ошибки, советую обновить PHP и решить первую проблему. Если не поможет, то нужно разбираться почему PHP получает SIGSEGV.
Замена TCP соединений на сокет не поможет. Проблема не в накладных расходах TCP соединений, а в увеличении нагрузки(времени обработки запроса).
Скорее всего ошибки, как то связанны.
Какие-то аргументы в пользу этого вы способны привести? Ну, помимо "эти строчки есть в одном и том же лог-файле" :D
Чтобы избавиться от первой ошибки, можно увеличить число процессов(pm.max_children) до 10-100.
А че мелочиться - давай до 1000 сразу.
А также разобраться
О, а вот с этого действительно стоит начать!
Какие-то аргументы в пользу этого вы способны привести? Ну, помимо "эти строчки есть в одном и том же лог-файле" :D
Да, могу привести аргументы. Например вызов какой-то функции стал медленным и поэтому стало не хватать количества процессов. SIGSEGV случается в этой же функции.
А че мелочиться - давай до 1000 сразу.
Достаточно увеличить в 2-20 раз, нет смысла увеличивать в 200 раз количество процессов.
О, а вот с этого действительно стоит начать!
Ссылка на инструкцию https://bugs.php.net/bugs-generating-backtrace.php
Проблему частично удалось локализировать, но как решить сабж не знаю.
Дело в том, что на сервере имеются медленные php-скрипты, которые долго выполняются, так как подтягивают данные извне посредством функции file_get_contents. Но это же не должно стать причиной того, что php падает. Как настроить php так чтобы медленные скрипты не влияли на работу php-fpm.
Да, могу привести аргументы. Например вызов какой-то функции стал медленным и поэтому стало не хватать количества процессов. SIGSEGV случается в этой же функции.
Самого "интересного" не рассказали - таки причем сегфолт к какой-то "медленности вызова функции"?
Тем паче, что "связь" настолько странная - что даже во времени никакой корреляции не видно. Или чукча просто не читатель?
Достаточно увеличить в 2-20 раз, нет смысла увеличивать в 200 раз количество процессов.
"Отсюда не видно", что имеет смысл увеличивать что-то даже и в два раза, не то что в 20. Забыли в подписи вывеску "лечим по фотографиям"?
Ссылка на инструкцию
Которая абсолютно никак не поможет ТС найти "тяжелые" скрипты.
Еще раз: баг в каком-то модуле php (пример возможной причины сегфолта) и наличие медленно работающих скриптов - связаны только вашей фантазией.