Очень странное поведение. Гугл неплохо запоминает, что вы помечаете как "не спам".
А ставя свой почтовый сервер в варианте "все без фильтрации во входящие" сразу почувствуете, почему гугл настойчиво фильтрует спам.
Яндекс не лучше, он по-другому немного. Но тоже может "перегнуть палку".
Может, вам у хостера поискать тариф "почтовый" (nic.r, timeweb.r, с другими не работал по тарифам почты). Возможно, проверки не будут столь драконовскими.
Может, вам завести отдельный VPS серверок (любой мощности) только для отправки и переадресации почты на основной сервер. Прописать SPF, что он имеет право отправлять почту.
На основном сервере проверьте по логам, нет ли странных авторизаций, отправок писем. Лог максимально подробно настройте. На вирусню проверьте сервер почтовый. Чудес не бывает. У вас Windows, вирусню подхватить легче, особенно если Windows лицом в мир стоит.
По опыту, на вирт. хостингах можно на один IP вешать несколько SSL сертификатов. Проверено. Вот, кстати, nexthop выше про SNI писал. Может и еще что-то есть. Хотя те сайты, которые чаще интересуют в плане статистики - крупные, они скорее всего не делят IP с кем-то еще. Хорошая мысль, спасибо.
АртемЪ: Если на диске LVM, то уменьшение раздела LVM может считаться улучшением "over provisioning"? Запас места есть, можно попробовать освободить гигов 50 спокойно.
chupasaurus: на запасном сервере с discard скорость поднялась до 80 МБ/с. Рву волосы, очень стыдно, жду возможности проверить на главном сервере. Спасибо.
Смотрел тут про особенности монтирования, предлагается использовать опции "defaults,noatime,discard". У меня просто все:
/dev/mapper/centos-root / ext4 defaults 1 1
Это не может быть причиной?
ОС CentOS 7, fs ext4. Обидно будет, если так себя ведет такая ось. Похожий комп, только с 2xSATA, такие же тесты, скорость 80 показывает.
НО! Что характерно, клиенты (да и я сам вижу это сильно) стали работать НАМНОГО шустрее, чем раньше (на этом сервере диски были заменены на SSD после огромных тормозов и длиннющих очередей по iostat. Может, есть что-то до неприличия простое, что я мог упустить?
Как я понял, в мобильниках стоит контроллер, который регулирует зарядку. Возможно, именно при приближении к полной зарядке сильно меняется сопротивление заряду со стороны телефона и повербанк просто сам думает, что раз такое дело - устройство заряжено. Защита от перезаряда устройств, в которых защита не так хороша, как у iPhone.
Или защита самого повербанка от сильного разряда его аккумулятора.
PS: сам постоянно заряжаю 6-ку оригинальной зарядкой от старого HTC на 1А. Оригинальной от Яблочников тоже не брезгую :)
Александр Коновалов: именно про них я и говорил. Посмотрите на ток на зарядных устройствах. Если не ошибаюсь, для 6 и 7 это 1,25А. Для 5-х айфонов на зарядках указан 1А. При этом iPad заряжается 2А.
Впрочем, если действительно так, как вы говорите, то и хорошо, меньше проблем.
А если перепутать 1А или 2А выходы на повербанке можно убить аккумулятор телефона. У меня парочка знакомых так до-заряжалась - вау, как быстро! - и привет, аккумулятор через месяц и трёх часов не держал.
У меня сейчас так: если я в prerouting маркирую пакеты с lan-интерфейса как "routing-mark=ISP1", то трафик идет через ISP1, если "routing-mark=ISP2", трафик идет через ISP2.
Если не делать ничего с mangle, вообще никуда ничего не идет.
/ip route print detail where routing-mark="ISP1"
0 A S dst-address=0.0.0.0/0 gateway=10.1.1.1 gateway-status=10.1.1.1 recursive via GW1 ether1 distance=1 scope=30 target-scope=10
routing-mark=ISP1
1 S dst-address=0.0.0.0/0 gateway=10.2.2.2 gateway-status=10.2.2.2 recursive via GW2 ether2 distance=2 scope=30 target-scope=1
routing-mark=ISP1
А ставя свой почтовый сервер в варианте "все без фильтрации во входящие" сразу почувствуете, почему гугл настойчиво фильтрует спам.
Яндекс не лучше, он по-другому немного. Но тоже может "перегнуть палку".
Может, вам у хостера поискать тариф "почтовый" (nic.r, timeweb.r, с другими не работал по тарифам почты). Возможно, проверки не будут столь драконовскими.