Jest неверно определяет количество процессоров в CI



Какое-то время мы испытывали странную проблему с джестом — он падал со словами out of memory, но при этом максимальные размер хипа (heap) ноды (2гб по умолчанию) не был достигнут, общий лимит джобы тоже.



Поиски привели меня в ишью Jest without --runInBand slow under Travis. Казалось бы, причём тут тревис? У джеста есть опция --maxWorkers, которая позволяет указать количество воркеров для прогона тестов. Чем больше воркеров, тем больше параллельных процессов, и тем быстрее тесты выполняются. Локально всё работает здорово, т.к. джест использует стандартное API require('os’).cpus().length. Проблемы начинаются в CI: например, Circle CI говорит, что доступно 32 процессора. Происходит это из-за того, что есть физическое кол-во процессоров, но каждой отдельной джобе доступна лишь какая-то часть.



В нашем случае проблема крылась в кубернетисе и его лимитах — nproc и нода говорили, что доступно 6 процов, но на деле настоящий лимит в 4 проца был указан через cgroup. Я написал небольшой баш-скрипт, который позволяет в таких случаях определить доступное кол-во. Там же ссылки на то, как работает менеджмент ресурсов в кубернетисе и ему подобным.



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



Но самое странное в изначальной ошибке: без ишью я бы никогда не догадался, что это проблема не с памятью, а с количеством воркеров.



P.S. Мэйнтэйнер джеста написал скрипт available-cpu и результаты, прямо скажем, забавные.