совершенно верно
учитывая еще то, что намешали разных понятий, тот же SSD тоже SATA интерфейс, то все выводы превращаются в сферического коня в вакууме
начнем с того, что SAS/SATA от интерфейса мало что зависит (просто производительные устройства выходят под SAS чаще, но тот же 10к SATA WD Раптор тоже очень даже ничего и будет покруче любого 7200 SAS'а), далее примерно следующее:
- 10к RPM = среднее время доступа 4-5 мс, производительность с БД примерно втрое выше, чем у 7200, работа с тучками мелких файлов (хранилище картинок и т.п.) в 1.5-2 раза быстрее
- 15к RPM = среднее время доступа 3 мс, производительность с БД в 5 раз выше, по картинкам в 2-2.5 раза
- дешевый SSD Crucial M4 256Gb = время доступа менее 0.5 мс, производительность с БД в 20 раз выше (типичного 7200 RPM SATA), с картинками примерно в 10 раз
причем все эти диски имеют примерно равную линейную скорость на запись, а на чтение SSD'шник быстрее остальных в 3 раза
а приведенные выше тесты с 800Мбайт/сек результатами и блоком в 100Мб вообще оторваны от реальности, так как это результат записи в "кеш" устройства
также не стоит dd'шкой тестировать SSD на базе контроллеров SandForce, вы все равно будете получать скорости равные скорости 600Мб/сек (т.е. потолок для интерфейса), всему виной сжатие на уровне контроллера, а непрерывные 0x00 хорошо сжимаются как известно 😂
также линейные тесты не годятся для сравнения SSD между собой, например серверный SSD Intel S3500/S3700 будет проигрывать практически в чистую десктопному Intel 520, но в реальных продакшн условиях будет в разы более броизводительный, как пример:
http://www.storagereview.com/images/intel_s3500_480gb_main_4kwrite_avglatency.png
показана производительность устройства при 16 потоковой записи, при 16 задач в очереди на запись, и серверный SSD в 4.5 раза обходит по скорости десктопный
что же в реальности сейчас на рынке - 600Гб SSD стоит дешевле 600Гб SAS, причем SAS проигрывает по всем факторам, кроме надежности (в плане % бракованных устройств), если боитесь за надежность SSD ставьте их в RAID-1, серверные версии SSD имеет смысл ставить под тяжелую и длительную нагрузку на запись, например под БД, также "серверные" SSD имеют примерно пятикратно большее число циклов перезаписи ячеек, чем десктопные SSD, но на практике даже при 40-50Гб ежедневной перезаписи десктопный SSD "стерется" примерно за 2-3 года, т.е. к этому моменту его уже можно заменить на новый, разница в цене между серверным и десктопным той же емкости примерно пятикратная :)
на LSI (при 1Gb DDR3) + RAID-1 из SSD, производительность на 30-40% выше (в т.ч. это касается и IOPS'ов), так что хороший контроллер дает плюсы даже там, где вроде бы и так все хорошо без него, а если брать LSI с обычными SATA + SSD кеш, то в плане БД прирост будет не такой впечатляющий, но для хостинга картинок разницы практически нет, что чистый SSD массив, что гибридный SATA+SSD, т.е. в таких случаях гибридная модель весьма оправдана, но БД все же лучше создавать на чистом SSD массиве (и желательно на "серверных" дисках)
рубрики имеет смысл плагином закрыть как noindex, follow, хотя это уже избыточные заморочки
все правильно делаете, все получится, через robots.txt + Disallow: имеет смысл закрывать только технические страницы, также имеет смысл заюзать rel="nofollow" на ссылках ведущих на теги, авторов, комментарии и т.п. (но на рубрики лучше сохранить ссылку без rel="nofollow")
через пару недель, если очень повезет, решите проблему, а вообще смените айпи у домена и проблема будет решена через несколько часов 🍿
что-то мне подсказывает, что ошибка не в пути, а в карме ТС, и его еще ждут новые приключения с конфигурированием nginx'а 😂
лишь бы не научились выполнять js 🍿
в данной ситуации хостеру надо было поступить проще:
- выключить сервер
- предоставить дамп (полиции и клиенту)
- давайдосвиданья клиенту
нет, надо просто нести ответственность за то, что у вас находится в управлении
в Раше когда силовики изымали по этой причине компы "на опыты", на возвращенных компах были девственно отформатированные жесткие диски (наличие вредоносного ПО на носителе уже само по себе печально) 🤪
скажите, а суммарный объем листинга ботов какой?
способ всегда есть, например - сменить хостера 😂
вот это хорошие новости
примерный подход работы такой:
1) получаете комп в распоряжение
2) делаете снимок жесткого диска и переносите в виртуальную машину
3) сравниваете чексуммы файлов (с известными эталонными), находите измененные файлы, изучаете заразу... по пути сбрасываете её в известные антивирусные конторки (через несколько часов ботнет начинет стремительно сокращаться теряя ботов с выходом обновления антивирусного ПО)
самим же разбираться с этой проблемой не имеет смысла, ну определили вы управляющие точки ботнета, дальше что? - абузить? - вашу абузу сложат в "корзину", надо сначала эту информацию довести до авторитетных ресурсов по кибербезопасности, а уже дальше пусть они разбираются с ботнетом
провайдеры обычно еще более абузоустойчивее, чем ДЦ, им наплевать на то, что айпишники их клиентов в каких-то черных списках
да ладно, сейчас у ботоводов ситуация кардинально поменялась, координация ботов идет по P2P механизмам (мгновенно практически), вычислить в этой схеме управляющие звенья и то очень сложно
