Добрый день! Спасибо за публикацию. Я хотел уточнить - а есть ли какие-то цифры по потреблению ресурсов машины при сжатии и тайминги процесса сжатия? Качество и размер это важные параметры, но вычислительные рессурсы также важны (возможно сжатие идет в 5 раз дольше чем jpg и ресурсов тратится в разы больше). Спасибо!
На самом деле проблема проявлялась на всех серверах с сервисом Б, но в момент начала исследования это было не очевидно, поскольку тайматили произвольные пары A и Б и таймауты происходили не массово (так как больших сообщений много меньше чем маленьких).
Этот момент у меня не получилось до конца раскопать, хотя я совершал несколько заходов. Возможно кто-то сможет подсказать здесь. Ниже приведу вывод iperf для разных конфигурация scaling. Как я писал, из того что получилось заметить, что iperf начинает подсвечивать наличие проблемы на географически удаленных ДЦ.
Запуск iperf3 на серверах в билзлежащих ДЦ c tcp_window_scaling = 1
[hostA~]# net.ipv4.tcp_window_scaling = 1
[hostA~]# iperf3 -c hostB -V
....
TCP MSS: 1468 (default)
[ 4] local hostA port 38440 connected to hostB port 5201 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1022 MBytes 857 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 1019 MBytes 854 Mbits/sec receiver CPU Utilization: local/sender 5.1% (0.2%u/4.9%s), remote/receiver 6.6% (0.5%u/6.1%s)
Запуск iperf3 на серверах в билзлежащих ДЦ c tcp_window_scaling = 0
[hostA ~]# sysctl net.ipv4.tcp_window_scaling=0
net.ipv4.tcp_window_scaling = 0
[hostA ~]# iperf3 -c hostB -V
...
TCP MSS: 1468 (default) [
[ 4] local hostA port 52814 connected to hostB port 5201 Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 913 MBytes 766 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 913 MBytes 766 Mbits/sec receiver
Как видно, незначительная деградация наблюдается, но цифры не бьются с реальной скоростью передачи.
Не до конца уловил идею про "момент" запуска таймаута. В нашем случае таймаут ограничивает разрешенное время передачи всего пакета (например, на случай тупящей сети) - если этого не сделать, сервис начнет деградировать в производительности (уменьшится rps) потому что будет стоять в отправку данных.
Если я правильно понял (поправьте, если нет), вы подковырнули настройки передачи, чтобы время отправки опустить в рамки погрешности. - в общем правильно. Подтюнили настройки TCP, чтобы "разогнать" пропускную способность.
Конфигурирование через тулы - это тоже ручное действие (имею ввиду написание самого конфига). У нас все сервера наливаются через автоматику и ручной кастомизации на серверах не происходит (только на момент экспериментов, с принудительном откатом до оригинальной конфигурации). В данном случае опция была прописана некорректно в самом конфигурационном файле, который разливался автоматикой на сервера.
P.S. Замечу, что конфигурация серверов не однородна по ряду причин, поэтому на части серверов были одни настройки, на части другие. После того как нашли проблему прошли по всем серверам и актуализировали опцию
В первую очередь начали исследовать сервисы, сервис А редко изменяется, а вот сервис Б обновляется довольно часто - поэтому сначала пошли в ту сторону. В сторону "железа" не смотрели до последнего, потому что изменения в конфигурации происходят крайне редко и по истории изменений никаких обновлений не было. Также в момент проблемы у нас было довольно много энтропии в системе: переход в кубер, постоянное обновления сервисов и т.п.
Когда я рефлексировал на тему того как можно было быстрее выйти на исходную проблему у меня пришло в голову только одно - правильно ставить эксперименты и более пристально проверять гипотезы.
А с проблемой доставки писем обращались в службу поддержки, и была ли она решена? Если нет, то присылайте номер тикета, мы узнаем подробности и разберемся.
А можете дать нам номер последней заявки, чтобы мы смогли проанализировать ситуацию?
Решение о блокировке писем принимается по совокупности факторов, одного нажатия кнопки «Это спам» недостаточно.
О факторах, которые могут повлиять на доставляемость писем, мы писали здесь: https://habrahabr.ru/company/mailru/blog/216535/
Общую информацию о правилах рассылок можно прочесть тут: https://help.mail.ru/mail-help/rules/info
А давно вы перестали пользоваться нашей почтой? Просто ситуация с добавлением пробелов и переводом строк кажется странной. В статье я упоминал о стадии нормализации, которая делает преобразования с текстом. После этого этапа лишние пробелы и переводы строк уже не существуют. Если возникают проблемы — пишите, разберемся.
Про добавления друзей в копию — как написал BigD в почте есть возможность отправить скрытую копию.
Такое имело место быть: как написал Matyushko существовала проблема с засвечиванием ящиков в других сервисах mail.ru, которой активно пользовались спамеры. На нашей стороне мы провели работу, чтобы улучшить защиту от ботов, которые используют эту информацию.
Добрый день! Спасибо за публикацию. Я хотел уточнить - а есть ли какие-то цифры по потреблению ресурсов машины при сжатии и тайминги процесса сжатия? Качество и размер это важные параметры, но вычислительные рессурсы также важны (возможно сжатие идет в 5 раз дольше чем jpg и ресурсов тратится в разы больше). Спасибо!
На самом деле проблема проявлялась на всех серверах с сервисом Б, но в момент начала исследования это было не очевидно, поскольку тайматили произвольные пары A и Б и таймауты происходили не массово (так как больших сообщений много меньше чем маленьких).
Спасибо большое за идеи! Постараюсь в ближайшее время проверить эти гипотезы.
Этот момент у меня не получилось до конца раскопать, хотя я совершал несколько заходов. Возможно кто-то сможет подсказать здесь. Ниже приведу вывод iperf для разных конфигурация scaling. Как я писал, из того что получилось заметить, что iperf начинает подсвечивать наличие проблемы на географически удаленных ДЦ.
Запуск iperf3 на серверах в билзлежащих ДЦ c tcp_window_scaling = 1
Запуск iperf3 на серверах в билзлежащих ДЦ c tcp_window_scaling = 0
Как видно, незначительная деградация наблюдается, но цифры не бьются с реальной скоростью передачи.
Не до конца уловил идею про "момент" запуска таймаута. В нашем случае таймаут ограничивает разрешенное время передачи всего пакета (например, на случай тупящей сети) - если этого не сделать, сервис начнет деградировать в производительности (уменьшится rps) потому что будет стоять в отправку данных.
Если я правильно понял (поправьте, если нет), вы подковырнули настройки передачи, чтобы время отправки опустить в рамки погрешности. - в общем правильно. Подтюнили настройки TCP, чтобы "разогнать" пропускную способность.
Вот этот момент похоже останется тайной, покрытой мраком
Личность садовника не так важна :)
Про проблему - имела место быть, сейчас все работает штатно.
Конфигурирование через тулы - это тоже ручное действие (имею ввиду написание самого конфига). У нас все сервера наливаются через автоматику и ручной кастомизации на серверах не происходит (только на момент экспериментов, с принудительном откатом до оригинальной конфигурации). В данном случае опция была прописана некорректно в самом конфигурационном файле, который разливался автоматикой на сервера.
P.S. Замечу, что конфигурация серверов не однородна по ряду причин, поэтому на части серверов были одни настройки, на части другие. После того как нашли проблему прошли по всем серверам и актуализировали опцию
Спасибо!
В первую очередь начали исследовать сервисы, сервис А редко изменяется, а вот сервис Б обновляется довольно часто - поэтому сначала пошли в ту сторону. В сторону "железа" не смотрели до последнего, потому что изменения в конфигурации происходят крайне редко и по истории изменений никаких обновлений не было. Также в момент проблемы у нас было довольно много энтропии в системе: переход в кубер, постоянное обновления сервисов и т.п.
Когда я рефлексировал на тему того как можно было быстрее выйти на исходную проблему у меня пришло в голову только одно - правильно ставить эксперименты и более пристально проверять гипотезы.
Спасибо! Суммарно ушло порядка 2 недель с учетом походов по ложным следам. Когда плотно сели за исследование, проблему нашли где-то за 3 дня.
Решение о блокировке писем принимается по совокупности факторов, одного нажатия кнопки «Это спам» недостаточно.
О факторах, которые могут повлиять на доставляемость писем, мы писали здесь: https://habrahabr.ru/company/mailru/blog/216535/
Общую информацию о правилах рассылок можно прочесть тут: https://help.mail.ru/mail-help/rules/info
Про добавления друзей в копию — как написал BigD в почте есть возможность отправить скрытую копию.