Зачем знать работу Go-планировщика для работы?
Привет! Очень часто я задумывался над тем, что всё это глубокое копание под капот гошки на собеседованиях - не что иное, как сублимация над языком из-за того, что он достаточно минималистичный и больше тупо нечего спрашивать. Очевидно, что в работе в 98% случаев тебя не особо парит, как шедулит шедулер или чистит garbage collector. Но хочу поделиться небольшим опытом с работы, когда понимание, как работает планировщик, спасло несколько часов, мб и дней, и мне не пришлось себе ломать голову.
В чём суть?
Очевидно, любой сервис у нас живёт в кубах, мы собираем его метрики и статистику, а также мониторим производительность. В один из дней у нас начал жёстко тротлить сервис по процессору, и надо было выяснить почему.
Во-первых, если вы работали с кубером и гошкой, то понимаете, что те лимиты, которые заданы на гошный сервис, например в 2 CPU, - это ограничения на стороне кубера, а гошка видит железо на сервере целиком. И если у вас не настроена правильно пресловутая переменная GOMAXPROCS, то мы приходим к ситуации, когда гошка пытается брать лишние ядра у тачки и упирается в полку, после чего кубер отшивает попытку взять лишние ядра, и загрузка скидывается с полки до низа. Собственно, это как раз состояние тротлинга, и казалось бы очевидно, что раз у нас лимиты 2 CPU, значит мы можем работать в 2 потока, и давайте ограничим GOMAXPROCS в 2.
Вроде бы проблема решена, но, к сожалению, нет. Мы всё равно продолжаем наблюдать тротлинг, и чтобы понять почему, давайте вспомним, как у нас работает планировщик. Кажется, что да: у нас есть ограничение в 2 CPU со стороны кубера, мы ограничиваемся двумя процессорами, которые ложатся на эти машины, и всё должно идеально работать. Но если мы начинаем мониторить время, которое горутины проводят в net-poller’е, выполняются на машине и так далее, то всплывает sysmon - именно он этим и занимается.
И тут возникает вопрос: как sysmon должен работать и иметь возможность завершать или прерывать горутины, если, например, у нас на обоих процессорах выполняются бесконечные горутины, которые не собираются заканчиваться? Очевидно, что его нельзя выполнять в рамках нашей GMP-модели. Поэтому его приходится запускать параллельно, в отдельном треде, без привязки к P. В итоге нам нужно выделять ещё один поток на стороне операционной системы, который и выполняет sysmon. При этом гошка, видя, что на железе, например, 64 ядра, даже несмотря на то, что мы залочены на 2 CPU, снова приходит к попытке использовать лишние ресурсы - и мы опять упираемся в тротлинг.
Поэтому, чтобы решить ситуацию с тротлингом, зная, как работает планировщик, я выставил GOMAXPROCS в 1 и спокойно решил проблему. Не знаю, сколько бы времени я убил, если бы даже в теории не представлял, что такое sysmon и как вообще работает планировщик.
