У клиента на одном из старых сайтов плохая капча. Постепенно его заспамили.
От техподдержки пришло сообщение следующего характера:
В адрес Вашего сервера поступила жалоба: Hello Abuse-Team, your server with the IP: 1.2.3.4 is currently hosting a possible scam-site. This site has reached an Blocklist-Spamscore of 4400. The concerning site is following site: http://ссылка/на-страничку Please check this site and do a cleanup if necessary. To resolve this case, please visit http://spamlinks.blocklist.de/resolve.php?case=xxx Your site was distributed by forums spam and therefor checked automatically for the possibility of spam at the site. This email is to inform you about maybe harmful content at your webspace. If the content is not harmful or unwanted, no action is needed - we did not blacklist you. You also can parse this mail with X-ARF tools that can be found at http://www.x-arf.org/specification.html . We found your address in the abusix abuse contact database at http://abusix.com/global-reporting/abuse-contact-db . If this contact is wrong, please inform info@abusix.com about this. Please do NOT reply at this email, use the contact form instead. Regards, Abuse-Team blocklist.de http://www.blocklist.de/en/ --- Reported-From: spamlinks@spamlinks.blocklist.de Category: fraud Report-Type: scam Service: http Version: 0.1 User-Agent: V.A.L.O.R. 1.0 Date: Wed, 12 Feb 2013 02:13:03 +0100 Source-Type: uri Source: http://ссылка/на-страничку Domain: домен Port: 80 Report-ID: xxx@spamlinks.blocklist.de Schema-URL: http://www.x-arf.org/schema/fraud_0.1.3.json Attachment: none Просьба проверить выше изложенный материал, разобраться в проблеме и сообщить нам о принятых действиях. Мы ждем Вашего ответа в течение 12 часов. C уважением, специалист службы поддержки FastVPS LLC
Собственно, в чем дело? Заражения сайта не произошло. Рассылка спама не осуществляется.
Почему в данной ситуации, по вашему мнению, клиенты должны нести срочные (12 часов) незапланированные расходы на какие-то там действия?
Что будет, если клиент сознательно ничего не сделает и напишет об этом?
Да, я понимаю что мир не станет лучше от такого сайта, но и не одобряю подобные паникерские письма. Ссылки как ссылки. Ну а вам-то что ?
Или закрыли встраивание для всех сайтов кроме разрешенных ?
Все болезни от нервов. Просто не смотрите туда.
Почти никак. Описание данное выше не соответствует действительности. Не так просто угадать в каких случаях на самом деле будет использован диск.
Но с набором патчей percona уже можно включить запись медленных запросов со временем 0 и выбрать те, которые помечены соответствующим образом.
Раз уж вы все равно решили делать tmpfs, это уже не важно.
если действительно идентичны и синхронизированы , это могут быть вибрации, повышенная температура, некачественный шлейф и тд. Все таки разница заметная.
Что-то подобное есть только не могу вспомнить какая именно модель карты. Думаю, что как то связано с проблемами той сети, где установлен сервер. Потому что в тестовом окружении вроде все работало.
Весьма противно, потому что такой глюк в принципе не позволяет войти удаленно в настройки bios. Нажимать кнопку нужно как раз в тот момент когда когда карта не отвечает.
еще очищается когда логика запросов на обновление делает информацию устаревшей.
т.е. очень простенький запрос на обновление одной ранее активно читаемой таблички может привести к очистке 2 гб кеша и запрос зависнет секунд на 10.
Так что кеш должен быть маленький.
А они не очень то парятся.
Вы смотрите на график объема последовательной записи . Это не так страшно как случайное чтение или настоящая фиксация транзакций.
Графики Disk utilization у вас уменьшились лишь в 2 раза.
Почему, кстати, они разные ? они не в идентичном raid ?
Да вы попробуйте список значений поменьше. Если план изменится - надо делать серию запросов. Или просто выражение force index. Ведь у вас там индексы в possible_keys перечислены, то есть в принципе могли бы быть использованы, но оптимизатор выбрал полное сканирование.
И кстати, есть интересные варианты скрещивания sphinx и mysql - отдельный storage engine для mysql, который фактически позволяет в одном sql-запросе объединять данные из sphinx и mysql. Но это больше для удобства.
Jackyk, нет. я имел ввиду изменения в vbulletin, такие чтобы они работали с этой конкретной схемой кеширования. Конечно, придется пожертвовать удобством пользователей.
И это тоже вариант. Потому что у многих программистов чужой код вызывает ступор.
ну так vboptimize и внутреннее кеширование - разные вещи.
Не на все фантазии найдется человек, который их реализовывал и выложил в инет. Зачем ждать? Берите и пишите. Благо версия 3.8 заморожена и изменения объединять не так уж сложно будет.
Не совсем. Не хуже чем у других, но хуже чем могло бы быть. У него от рождения косяк. Проблема действительно есть.
Продукт, продающийся поштучно лицензиями на домен не может учитывать интересы крупных форумов. Им выгодно развивать удобства для мелких, так как это больше способствует продажам. Даже где-то на сайте официально написано что позиционируется для "small to middle size forums".
В данном случае удобство отметки прочитанных тем и возможности учета сессий незалогиненых поставили важнее производительности.
Еще, может быть, дело просто в наследии.
Можно решать проблему (другую, не с сессиями) установкой продуктов. И даже какой-то из вариантов vboptimize на searchengines светился в подвале одно время. Но сейчас не светится.
Внутренние кеширования данных datastore в memcached или apc реализованы, но эффект на одном сервере малозаметен. Там контента нет, а только оперативная информация нужная почти каждому скрипту в составе форума. С тем же успехом можно просто надеяться на кеш запросов mysql.
...в ряде сеонизаторских CMS, в которых нет развесистой системы ограничения доступа и все пользователи видят одно и то же.
это если ваш форум cуществует с чисто сеонизаторской целью.
Когда люди размещают сообщение, они предполагают что его прочитают тут же, а не завтра. Даже обозначенные 10 минут уже вызовут недопонимание.
