Sergej Qkowlew

Есть подозрение, что свежайший (ну по крайней мере для FreeBSD и CentOS) memcached имеет memory-leak/buffer overflow баг, приводящий при некоем значении поступившего ему на вход url с буквами нац алфавитов (сорри, не нашёл точно в логах какой строкой это случилось) к выжиранию 2^32 байт памяти одной порцией (то есть вот так прямо +4 гигабайта в top ему прибавляется сей же секунд), причём ПРЕОДОЛЕВАЯ стоящее при запуске ему ограничение (там у меня было 1 гиг выделено). Всё это в достаточно типовом построении "nginx берёт из мемкешеда то, что туда положил php код вордпресса, битрикса или какой другой CMS"

От операционки вроде не зависит - в CentOs и FreeBSD эффект наблюдался примерно одинаково.

Это у меня два разных сервера стали недавно систематически падать и-или подвисать. Исследование показало, что, добавив им по 40 гигабайт свопа на тормознутом бекапном винте, я смог пронаблюдать "плавный" процесс "отжирания 4гиг мемкешедом" до того, как система впала в ошибку "не могу выделить свап спейс, пошли прибьём тут кого-нибудь..."

Особенная красота ситуации на одном из серверов заключалась в том, что кеширование объектов в WordPress "вдруг" переставало работать для подавляющего большинства страниц сайта, что приводило к возрастанию числа SQL запросов к базе с 10 до 740 и с 28 до 3000 и ещё более, в результате всё подыхало прямо на глазах. Пример честно закешированной как html файл такой страницы - вот тут. видно 747 запросов к MySQL 8-)

Сил раскопать самому этот кусок кода вот прям щас нету. :(

QSAN TrioNAS LX U600Q-D212, воткнут десятигигабитным портом в свитч SG500X-24.
Мак Ось X. На Маке - гигабитная сетевуха, воткнут в тот же свитч.
Windows - домен на 2003/2008 сервере, МАК вогнан в домен, NAS вогнан в домен. Пользователи все понимаются, проблем с правами доступа как таковыми не обнаружено.

Мак по smb:// протоколу присоединённый к NAS - имеет скорость записи на нас 26-30 мегабайт в сек (от тюнинга net.inet.tcp параметров не зависит).
Мак по afp:// - имеет скорость 110 мегабайт в сек (после sysctl тюнинга net.inet.tcp параметров, до тюнинга было 75-89 мегабайт в сек).
на nfs:// 38-43 мегабайт в сек


При работе по smb:// и nfs:// Final Cut Pro не ругается, File Type считает нормальным.
При работе по afp:// Final Cut Pro ругается "File: Wrong type" на ЧАСТЬ открываемых (по клику из Finder'a) файлов.

Вопрос:
1. Эту ошибку "в рамках самого мака" как-то послать нафиг-проигнорировать-компенсировать можно, или нет?
2. Можно ли поднять скорость работы Мака по smb:// или nfs:// протоколу до более разумных?
3. Какие ещё решения Вы можете предложить?

UPD: добавил информацию о результате тестирования nfs

( Подробнее с симптомами )