LINUX.ORG.RU

Rust приложение раздуло в 20 раз при запуске в Kubernetes/CoreOS

 , , , ,


0

9

Написал два Hello World вебприложения. Одно на Go - самое простое, другое на Rust - на Iron Framework. Оба возвращают одно и то же на любой HTTP запрос.

Запускаю оба сервера в docker.

Go жрет 4 МБ, Rust - 7 MB памяти. Rust по идее должен быть более экономным, но в данном случае в Go используется стандартный сервер, а в Rust - сторонний фреймворк. В любом случае разница - мелочь.

Запускаю все в Kubernetes, тоже в docker. Rust раздувает до 130 МБ (RSS), в Go ничего не поменялось. Думаю, ну наверное Go - статический бинарь без libc, а Rust - зависит на glibc. Ведь дейсвительно, Go запускается в образе Busybox, а Rust - в Ubuntu. Memory sharing показывает малый и там и там, и даже на локалке. Даже если запустить 3 процесса с Rust - все жрут 130 MB. Rust бинарь собирал в Gentoo, запускал на Ubuntu. Оно запороло какую-то оптимизацию?

И тут я сделал третий эксперимент. Я сделал такой-же сервер на Python. Он благополучно выжрал 13 MB в Kubernetes. D 10 раз меньше Rust

Я смотрю Rust готов к продакшну по полной программе. У меня руки не доходят его собрать с Musl, посмотреть.

Идеи, предложения? Ведь Rust таки жрал 7 MB на локальном докере в Gentoo. Почему так раздуло с Ubuntu libc на ядре CoreOS, причем только его одного?

Update: Пересобрал в статический бинарь с Musl и засунул в голый Busybox образ в котором даже каталогов /lib и /usr/lib нету. Локально стало меньше жрать, жрет 1.5MB. В Kubernetes - 130MB все равно.

Solved: Rust cоздавал 64 потока, потому что у него количество потоков - num_cpu * 8. На локальной тачке тоже, но непонятно почему локально не использовалось так много памяти

Solved2: man overcommit

★★★★★

Вы хоть релиз собрали? А то наезд жиденький.

Потребление памяти в Rust на уровне плюсов, так что или проблемы с оценкой занимаемой памяти, или Iron кривой, что не проблема языка.

RazrFalcon ★★★★★ ()

Написал два Hello World вебприложения.

Hello World

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

Manhunt ★★★★★ ()

Идеи, предложения?

Выкинь какаху. Пусть мозилла сначала сама на нём что-то путное запилит, а то складывается впечатение, что они сами его не юзают.

anonymous ()
Ответ на: комментарий от Manhunt

Вывод в раздувании только Rust в 20 раз всего лишь в разных сторонних условиях. И 130 мб - явно много для web hello world языка категории C++

vertexua ★★★★★ ()
Ответ на: комментарий от anonymous

Мне кажется тут наоборот зарыта интересная возможность узнать новые нюансы работы памяти, ядра или glibc

vertexua ★★★★★ ()

Сделаю потом еще эксперименты

Собрать Rust приложение в том же контейнере с той же libc

Собрать Rust с musl статически.

Попробовать другой фреймворк

vertexua ★★★★★ ()
Ответ на: комментарий от vertexua

Но это же вроде бы самый популярный фреймворк.

Меня веб не интересует - не в курсе.

RazrFalcon ★★★★★ ()

в Rust - сторонний фреймворк

ИМХО дело именно в нем.

anonymous ()
Ответ на: комментарий от vertexua

На голом hyper попробуй. Если не ошибаюсь, то большинство фреймворков на его основе написано.

Kilte ★★★★★ ()
Последнее исправление: Kilte (всего исправлений: 2)
Ответ на: комментарий от RazrFalcon

так что или проблемы с оценкой занимаемой памяти

Смотрю RSS. Плюс его убивает oom killer если дать контейнеру меньше 100 MB. Как не меряй, без 100 мб не работает

vertexua ★★★★★ ()
Ответ на: комментарий от vertexua

Еще можно попробовать отключить jemalloc, но это только на nightly.

RazrFalcon ★★★★★ ()

jemalloc мегабайт 8 преаллоцирует. У каждого thread'а стек мегабайта по 2. Сколько потоков в процессе?

red75prim ★★ ()
Ответ на: комментарий от vertexua

Мне кажется тут наоборот зарыта интересная возможность узнать новые нюансы работы памяти, ядра или glibc

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

А крутить тебе, вероятно, нужно настройки аллокатора.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Твой пост был бы лучше если в нем оставить второй абзац

vertexua ★★★★★ ()

Update: Пересобрал в статический бинарь с Musl и засунул в голый Busybox образ в котором даже каталогов /lib и /usr/lib нету. Локально стало меньше жрать, жрет 1.5MB. В Kubernetes - 130MB все равно.

vertexua ★★★★★ ()
Последнее исправление: vertexua (всего исправлений: 1)

Пока что рано оценивать раст в вебе — Iron+Hyper единственные более-менее пригодны к использованию и в Hyper все еще не запилили асинхронность.
Как только переведут IO на futures и tokio-стек, можно будет посмотреть как это скажется на производительности и жоре памятти

mersinvald ★★★★★ ()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от mersinvald

Запустил демку на чистом hyper, количество тредов с десяток. Жрет 40М. Кажись мы ближе к проблеме. Сейчас посмотрю количество тредов на iron

vertexua ★★★★★ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от mersinvald

А что-ты делаешь Rust прекрати. В Iron оно создало 68 потоков. 68 потоков, Карл!

Кажись проблема почти решена. Единственно что остается неясным - почему локально оно жрет 10МБ, хотя делает 70 тредов.

У меня как-то управление памятью по разному настроено?

vertexua ★★★★★ ()
Ответ на: комментарий от makoven

А, понятно, спасибо. Забавный у них коммент

Defaults to a threadpool of size `2 * num_cpus`

а потом код

8 * ::num_cpus::get()

Но код все обьясняет

vertexua ★★★★★ ()
Ответ на: комментарий от vertexua

Хах) Точно, не обратил внимания. Даже issue на эту тему есть, но всем, видимо, пофиг

makoven ★★★★★ ()
Ответ на: комментарий от makoven

флагманский проект раста в вебе

А почему кому-то должно быть не пофиг на него? Это такая же тупость как и плюсы в вебе.

anonymous ()
Ответ на: комментарий от anonymous

Это такая же тупость как и плюсы в вебе.

Плюсы в вебе - это как минимум гугль, яндекс, пейсбук и пр.

anonymous ()
Ответ на: комментарий от anonymous

вывсёврети! уних всё на лишпе!111

anonymous ()
Ответ на: комментарий от anonymous

Плюсы превращенные в Rust с помощью библиотек, статического анализа и запретов на фичи

vertexua ★★★★★ ()
Ответ на: комментарий от anonymous

Сколько в вебе гуглов и сколько остальных сайтов (которые понимаются под обычным «вебом»)?

На уровне гугла/фейсбука все равно придется разрабатывать свои решения.

Еще кстати было бы интересно узнать, сколько из гугловых сервисов кроме поиска работает на плюсах.

anonymous ()
Ответ на: комментарий от anonymous

А какие варианты? Выбрать Го и мириться с его дизайном: «Мы парни простые: написали язык в 60-х - напишем и сейчас».

Или выбрать PHP/Python/Ruby, которые из-за волчанки GIL придется обмазать mod_php/fastcgi/uwsgi/другим_д***мом_из_90-х? А когда понадобится мультипоточность, убеждать себя и окружающих, что «потоки не нужны, микросервисы рулят»

Или может пойти в ногу со временем и писать серверный код на браузерном языке сценариев от Netscape?

Что мне выбрать, анон? Наставь меня на путь истиный

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от AnDoR

Common Lisp, очевидно.

Не очевидно :-) Common Lisp - это абстракция :-) Правильнее называть конкретную реализацию, сразу обозначая связанные с ней специфические проблемы, коих не мало :-) Общие же проблемы таковы:

  • сложный (очень);
  • старый (стандарт от 1994 года);
  • сомнительный в плане надёжности и дальнейшего развития. [/lisp] :-) Как следствие, на нём пишут единицы :-)
anonymous ()
Ответ на: комментарий от makoven

микросервисы рулят

Почему нет? Вон гитхаб на руби написан и ничего, побольше серверов в аренду и любую нагрузку держит. Это все равно дешевле чем грамотные разработчики.

redixin ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.