Лев Евсеенко@evseenkolev
Системный администратор
Информация
- В рейтинге
- Не участвует
- Откуда
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Работает в
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Системный администратор, DevOps-инженер
Средний
Можете поделиться примерными метриками кластера, пожалуйста? Для примера, задержками AddActivityTask, StartWorkflowExecution? Контекст вопроса - недавно запускали в тестовом режиме кластер Temporal, и задержки оказались достаточно нестабильными, особенно на малых нагрузках, и отличаются в 2-3 раза от примерных целевых параметров для Temporal Cloud из документации.
Делали ли какие-то дополнительные настройки кластера для увеличения производительности? Вообще, было бы интересно почитать техническую сторону вопроса именно по запуску и обслуживанию кластера - документация(во всяком случае раньше) была не очень подробной для OSS-решения.
Если я правильно понимаю - МДФ там тоже разное, судя по маркировке на фокусировочном кольце - около метра. С макрокольцами все возможно, конечно, но с ними я могу поставить и современную оптику.
На пленке или для портретов его наверное было достаточно, но я как-то решил попробовать его в качестве макро-объектива на полнокадровой Sony A7m3. Мне совсем не понравилось, изображение слишком мягкое, кольцо диафрагмы мелкое и никак не фиксируется в промежуточных положениях, фокус очень тугой(скорее всего мне не повезло с экземпляром), да и с макро все оказалось совсем не радужно - насколько я понял, макро-возможности есть только у Л/З, у Л/Д их нет. Благо, этот эксперимент обошелся мне в ~1000р за объектив и переходник, но больше я в эту сторону не пойду, наверное.
"Справляется" это немного необъективная оценка. i5-9600K, в целом, тоже справляется - я могу играть, и FPS часто даже не меньше 60. Но имея монитор с высокой частотой обновления очень грустно видеть, что видеокарта недоутилизирована, и все могло бы быть сильно лучше.
Я тоже так думал, и в 2023 году купил себе RTX3080, в пару к своему i5-9600K. По итогу я получил загрузку ЦП в 95%+ и загрузку ГП в 35-40%. Игры - Escape From Tarkov, The Witcher 3 Next-Gen Update. Даже в Dota 2 я не смог получить стабильные 160FPS+ в 1440p. Собираюсь переходить на 9900X, потому что ценник даже на 9800X3D не особо гуманный.
На самом деле хороший вопрос, но честно говоря - я уже не помню :) Посмотрел сейчас, упакованный gzip образ занимает 6.6ГБ. Вероятно, раньше мы его не так сильно сжимали, либо из-за того, что складывали его в память + накладные расходы на сервисную ОС и у нас получилось больше 16ГБ, поэтому в требования написали 32ГБ.
Именно перед установкой мы только проверяем что железо в сервере фактически соответствует тому, что у нас записано в БД бэкэнда. После сборки сервера(но перед его передачей в пул доступных для клиентов) мы проводим подробное тестирование комплектующих, включая стресс-тесты ЦП/ГП, тесты памяти, температурные тесты и тесты дисков(SMART, скорость чтения/записи). Между арендами проверяем SMART'ы дисков, версии прошивок устройств и коротким стресс-тестом(около 10 минут) проверяем процессоры на перегрев/тротлинг.
Я коротко описал это в статье, используем Ansible, inventory которого автоматически генерируем, используя API. Проверяем разметку дисков(соответствует ли нашей разметке по-умолчанию), пароль, доставку SSH-ключей, пакетные зеркала, список установленных пакетов, версию ОС, список пользователей с интерактивными сессиями. Сейчас проверяем сами, глазами, экспортируя лог выполнения Ansible на серверах в артефакты GitLab. Скорее всего в будущем будем автоматизировать и этот этап.
Предполагаю, что вы имеете в виду DISM, как способ доставки драйверов в образ. Способ хороший, но у него есть особенность - для его использования нужна Windows, а у нас в инфраструктуре она не используется. Вместо этого, мы монтируем каталог с драйверами в виртуальную машину, и добавляем в unattend.xml использование модуля Microsoft-Windows-PnpCustomizationsNonWinPE.
Как автор материала по сборке образа, могу сказать следующее:
Предложение использовать nfsroot связно с процессами очистки, как я понимаю. В нашем случае служебный дистрибутив также запускает автотесты и помогает нашим инженерам в диагностике, чего можно добиться, только запуская ОС на целевом железе;
Arch Linux используется потому, что действующие процессы уже были построены на нем, а полностью менять дистрибутив (или поддерживать два одновременно) нам кажется нецелесообразным. Аргументы почему изначально был выбран Arch я писал здесь в комментариях. Если коротко — свежее ядро для поддержки нового железа и легкость модификации под наши задачи.
Для нас Arch достаточно стабилен, чтобы не переживать по этому поводу. Gentoo действительно не используется в нашем департаменте, плюс сборка оптимизированного образа займет много времени — для наших задач это бессмысленно.
Привет! В случае выделенных серверов в Selectel мы никак не модифицируем установочные образы.
По поводу российских линуксов - Игорь немного проспойлерил :) Мы действительно готовим Astra Linux для выделенных серверов, но пока я не могу сказать, когда будет готово.
Обычно раз в месяц-полтора. "Просто так" обычно не обновляем - чаще всего пересобираем в связи с расширением функциональности.
Есть несколько причин - нам нужно максимально свежее ядро для поддержки нового железа, относительно просто модифицировать образ для наших потребностей, отсутствие лишних пакетов. Ну и самая главная - так исторически сложилось :)