Bug 9188

Товарищ с 95.71.42.61 многочисленными запросами к
http://apologet.spb.ru/ru/69-00/08/%D0%B3%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%BE"
убил сервер:
страница формировалась по 140 секунд!

Надо срочно докопаться и исправить, сайт стал очень напрягать.

(В ответ на comment #0)
> http://apologet.spb.ru/ru/ddd/admin/index.php?login=yes&lang=en

Странная страница, таких не должно быть на сайте.
Открывает долго, ничего на странице нет.
Вообще должно возвращать 404 страницу, но сайт это игнорирует.
Грузит долго, т.к. обработчик не понимает что написано в URL и пытается получить данные подставляя эти аргументы. http://apologet.spb.ru/en/ddd/8-admin - открывает нормально по ID не смотря на категорию.

(В ответ на comment #1)
> Товарищ с 95.71.42.61 многочисленными запросами к
> http://apologet.spb.ru/ru/69-00/08/%D0%B3%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%BE"
> убил сервер:
> страница формировалась по 140 секунд!

Исправил кеш, права файлов, пути к логам и временным файлам на сайте. Вроде заходит нормально на все страницы.

(В ответ на comment #3)
> (В ответ на comment #0)
> > http://apologet.spb.ru/ru/ddd/admin/index.php?login=yes&lang=en
> 
> Странная страница, таких не должно быть на сайте.
Ну это просто левый запрос.

> Открывает долго, ничего на странице нет.
Да.

> Вообще должно возвращать 404 страницу, но сайт это игнорирует.
Это ошибка. Должно возвращать сразу.

> Грузит долго, т.к. обработчик не понимает что написано в URL и пытается
> получить данные подставляя эти аргументы. http://apologet.spb.ru/en/ddd/8-admin
Это можно исправить?

Сейчас умный движок делает вот такой запрос по левым обращениям:
SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = 0 THEN a.created ELSE a.modified END as
     modified, a.modified_by, uam.name as modified_by_name, CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END as publish_up, a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey,
     a.metadesc, a.access, a.hits, a.xreference, a.featured, LENGTH(a.fulltext) AS readmore, CASE WHEN badcats.id is not null THEN 0 ELSE a.state END AS state, c.title AS category_title, c.path AS
     category_route, c.access AS category_access, c.alias AS category_alias, CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author, ua.email AS author_email, contact.id as
     contactid, parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias, ROUND(v.rating_sum / v.rating_count, 0) AS rating, v.rating_count as rating_count,
     c.published, CASE WHEN badcats.id is null THEN c.published ELSE 0 END AS parents_published
  FROM j17_content AS a LEFT JOIN j17_content_frontpage AS fp ON fp.content_id = a.id LEFT JOIN j17_categories AS c ON c.id = a.catid LEFT JOIN j17_users AS ua ON ua.id = a.created_by LEFT JOIN j17_users AS uam
     ON uam.id = a.modified_by LEFT JOIN (SELECT contact.user_id, MAX(contact.id) AS id, contact.language FROM j17_contact_details AS contact
  WHERE contact.published = 1
  GROUP BY contact.user_id, contact.language) AS contact ON contact.user_id = a.created_by LEFT JOIN j17_categories as parent ON parent.id = c.parent_id LEFT JOIN j17_content_rating AS v ON a.id = v.content_id
     LEFT OUTER JOIN (SELECT cat.id as id FROM j17_categories AS cat JOIN j17_categories AS parent ON cat.lft BETWEEN parent.lft AND parent.rgt WHERE parent.extension = 'com_content' AND parent.published != 1
     GROUP BY cat.id) AS badcats ON badcats.id = c.id WHERE a.access IN (1, 1) AND c.access IN (1, 1) AND CASE WHEN badcats.id is null THEN a.state ELSE 0 END = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR
     a.publish_up <= '2013-03-28 12:18:37') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2013-03-28 12:18:37') AND a.language in ('ru-RU', '*') AND (contact.language in ('ru-RU', '*') OR
     contact.language IS NULL) GROUP BY a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, a.created, a.modified,
     a.modified_by, uam.name, a.publish_up, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.fulltext, a.state, a.publish_down, badcats.id, c.title, c.path, c.access,
     c.alias, uam.id, ua.name, ua.email, contact.id, parent.title, parent.id, parent.path, parent.alias, v.rating_sum, v.rating_count, c.published, c.lft, a.ordering, parent.lft, fp.ordering, c.id, a.images,
     a.urls
  ORDER BY a.created DESC
  LIMIT 0, 20

Можно на host03 посмотреть лог
/var/log/nginx/apologet.spb.ru-access.log
там предпоследним в строке пишется затраченное на страницу время.

Что-то уже каждая страница формируется очень долго:
tail /var/log/nginx/apologet.spb.ru-access.log
109.207.13.25 - - [31/Mar/2013:18:55:36 +0400] "GET /ru/990.html HTTP/1.1" 200 16586 from "-" 5.573 "apologet.spb.ru"
109.207.13.25 - - [31/Mar/2013:18:55:45 +0400] "GET /ru/521.html HTTP/1.1" 200 20973 from "-" 5.979 "apologet.spb.ru"
109.207.13.25 - - [31/Mar/2013:18:55:52 +0400] "GET /ru/874.html HTTP/1.1" 200 26552 from "-" 5.496 "apologet.spb.ru"
109.207.13.25 - - [31/Mar/2013:18:56:01 +0400] "GET /ru/681.html HTTP/1.1" 200 30002 from "-" 6.414 "apologet.spb.ru"
109.207.13.25 - - [31/Mar/2013:18:56:09 +0400] "GET /ru/830.html HTTP/1.1" 200 13406 from "-" 5.802 "apologet.spb.ru"
109.207.13.25 - - [31/Mar/2013:18:56:20 +0400] "GET /ru/678.html HTTP/1.1" 200 11646 from "-" 5.547 "apologet.spb.ru"

Обращения может и правые... Похоже, это вывод колонки новостей, например. Тормоза из-за выключенного кэша. Может быть, это мультиязычие так плохо влияет?
Включил кэширование (APC), разницы не заметил. Каждая страница формируется около 5 секунд. Повторно, конечно, быстрее, но последовательный перебор всех страниц (индексирование) убивает сервер.

(В ответ на comment #6)
> Может быть, это мультиязычие так плохо влияет?

Не думаю, язык формируется перед началом запросов.

Добавил git репозиторий в корень сайта, для проверки изменений.
Проверил файлы сайта, нашел 6 эксплоитов, 4 их которых загружены как модули, удалил.
Так же нашел 3 фрейма, которые подгружали сторонние сайты, не имеющие отношение к статистике или поисковым системам.
Увидел перебор пароля админки с адреса 46.233.196.185, заблокировал.
Все это не имеет отношение к тяжелым запросам движка сайта, но это могло крашить сервер. Продолжаю наблюдать, изменится ли ситуация.

(В ответ на comment #7)
> ...4 их которых загружены как модули...

Вполне возможно кто-то имеет доступ к панели администратора сайта, для безопасности лучше сменить все пароли.

(В ответ на comment #7)
> Добавил git репозиторий в корень сайта, для проверки изменений.
> Проверил файлы сайта, нашел 6 эксплоитов, 4 их которых загружены как модули,
> удалил.
> Так же нашел 3 фрейма, которые подгружали сторонние сайты, не имеющие отношение
> к статистике или поисковым системам.
Слушай, а как полезно сайт в git запихнуть :)

...
Мне почему-то только сегодня Google прислал в 4 ночи:
http://apologet.spb.ru/ заражен вредоносным ПО

> Увидел перебор пароля админки с адреса 46.233.196.185, заблокировал.
Когда блокируешь, имей в виду, что в контейнер с Apache обращается nginx, всегда с одного адреса. Поэтому блокировать надо в хост-системе.

Откладываем задачи, к которым не обращались более 100 дней.

Сегодня обнаружил, что когда были эти единички, страница открывалась по 6 сек:
--- a/configuration.php
+++ b/configuration.php
@@ -67,8 +67,8 @@ class JConfig {
        public $memcache_compress = '1';
        public $memcache_server_host = 'memcached';
        public $memcache_server_port = '11211';
-       public $memcached_persist = '1';
-       public $memcached_compress = '1';
+       public $memcached_persist = '0';
+       public $memcached_compress = '0';
        public $memcached_server_host = 'memc

Пытался побороть через webgrind и xdebug + cachegrind, но не смог.