- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Проблема состоит в том, что работа с админской части происходит очень медленно. Битрикс работает на выделенном сервере, сервере настроен в соответствии с рекомендациями из "Панели производительности". PHP 5.3 работает как модуль Apache, Apache - в связке с nginx, установлен XCache. Пытаясь выяснить, в чем проблема, включили дебаг для sql-запросов битрикса. В нем видно, что некоторые простые запросы по каким-то причинам выполняются очень долго. Например:
TIME: 7.9682328701 SESSION: 1fa7a17ff471c8c812224b8e85c553a5 CONN: Resource id #15
SELECT CATEGORY, NAME, VALUE, COMMON FROM b_user_option WHERE (USER_ID=1 OR USER_ID IS NULL AND COMMON='Y')
При этом тот же запрос выполняется через PhpMyadmin за 0.0111 сек. Приведенный выше запрос выполняется Битриксом от 6 до 16 секунд. Непонятно, с чем это связано и как можно эту ситуацию исправить.
При этом иногда Apache не успевает отдать контент nginx, и запрос завершается 502 или 504 ошибкой. При этом в логах Apache ничего нет, и даже непонятно, какой запрос (или не запрос) стал критическим.
сервере настроен в соответствии с рекомендациями из "Панели производительности".
тоже мне, икона оптимизации.
При этом в логах Apache ничего нет, и даже непонятно, какой запрос (или не запрос) стал критическим.
а для этого есть лог медленных запросов в mysql, который отдельно от битрикса
Ну покажи show global variables. Весь набор вставь не картинкой, а текстом. Можно как вложение .txt.
Если откровенной лажи нет, то тут имеет смысл только изучение ситуации на месте.
На вскидку - слишком большой query_cache_size.
Включили лог медленных запросов - в нем видно, что запросы к таблице с инфоблоками (iblock), с несколькими JOIN-ами, выполняются 3-7 секунд. query_cache_size был 16M, сейчас поставили 8 - вроде особо ничего не поменялось. Пробовали вообще отключать кеш запросов (ставить 0) - тоже не лучше. Результат show global variables в приложенном файле.
Проблемы с кешем возникают у тех, кто сильно увеличивает query_cache_size до нескольких сотен мегабайт, думая что тем самым повышает шансы на кеширование запроса. У вас вроде не так.
key_buffer = 16M . что так мало ?
А что innodb отключен ? У вас действительно bitrix ? по-моему их рекомендации как раз подразумевали innodb и ряд специальных (немного даже снижающих надежность) настроек для innodb.
Если lock time в этих медленных запросах большой, то однозначно надо переходить на innodb.
"инфоблоки" ведь используются чем попало, в том числе и самописными модулями не из поставки bitrix. может быть там запрос просто не продуман?
Вообще, гадать на форуме дело непродуктивное. Попробуйте что-ли скрипт mysqltuner.pl в качестве советчика, но отнеситесь к советам очень критически.
Не нужно увеличивать бесконечно всякие вторичные кеши, если он продолжает советовать повышать, но вы видите что в поведении сервера ничего не меняется.
С проблемой разобрались. Выяснилось в итоге, что Битрикс не стоит ставить на scale server, так как Битрикс запрашивает доступные ресурсы при инициализации, scale server возвращает минимальные значения, с которыми Битрикс и работает в дальнейшем. Поэтому в итоге запущенным процессам не хватало памяти, из-за чего все работало очень медленно и появлялись ошибки nginx. Спасибо за помощь, mysql еще будем настраивать теперь уже на обычном виртуальном сервере.