среда, 1 февраля 2017 г.

Оптимизация Squid 3+: Часть III

Архитектура (продолжение)

Асинхронные задания

Все было бы совершенно печально в одном потоке, если бы не некоторые девелоперские ухищрения. С некоторой натяжкой можно считать Squid частично-параллельным, так как некоторые движения в нем выполняются как асинхронные задания (этот параллелизм так тонок, что его почти не видно. В частности, вы не увидите появления LWP, как бы ни напрягали зрение, вглядываясь в вывод top). 

В действительности, асинхронные задания - это совершенно не то же самое, что и честные треды, так что вы так и будете видеть один-единственный тред, выполняющийся на одном ядре и точка. И при подвисании, скажем, асинхронного задания подвиснет весь Сквид целиком.

Кстати, не спешите материть разработчиков. Чтобы переписать весь код в thread-aware, надо бОльшую его часть по факту написать заново (вы проклянете только синхронизацию, когда увидите, сколько глобальных переменных и данных вам надо будет защищать мьютексами. И можете даже не заикаться про atomic - это будет еще больше работы и вряд ли получится. Можете попробовать).

Масштабирование

Исходя из всего вышесказанного, следует понять и усвоить следующее.

Возможности по неограниченному масштабированию базовой архитектуры Squid очень сильно ограничены.

Причем масштабирование на одну большую машину весьма быстро упрётся в встроенные ограничения (самое радикальное из которых заключается в том, что Squid внутри далеко не во всех местах 100% 64-битный. Вот так, чешуйчатые. Сюрприз. Я не говорю, что его нельзя собрать в 64 бита. Можно. Только вот указатели и типы данных внутри далеко не все окажется 64-битными. И если вы наивно попытаетесь от собранного кода получить лимиты истинно 64-битного кода, вас ждет нехилый сюрприз). Постепенно и очень неспешно код правится, однако лишь когда репортится действительно фатальный и воспроизводимый баг, связанный с этим кодом.

Главным сюрпризом является тот факт, что большие машины в настоящее время уже  не SMP, а CMT. Соответственно, собственная архитектура SMP в Squid на таких машинах поведет себя.....эээээээ..... несколько не так, как ожидают разработчики.

Из вышесказанного вытекает вот что. Одиночный инстанс Squid лучше не раздувать до небес (выигрыш очень быстро будет перекрыт административными затратами на сопровождение и аномалиями в поведении), а оставить его маленьким. И масштабировать Squid как Grid, то есть создать кластер относительно некрупных кэшей-сиблингов с мощным горизонтальным интерконнектом а-ля-кластер, или иерархическую структуру - двух- или трехуровневую. Возможно - но не обязательно - с использованием CARP.