Curl жрет 158 Мб !!

«кушает» весьма прилично - 158 мб RAM! Памяти на сервере совсем не много

Ты хоть номер карты напиши, непонятно куда кидать пожертвования на модуль памяти в 256Мб.

Так у меня 100+ инстансов!

Если эти процессы curl запускаются под отдельным пользователем, можешь настроить для него ограничения.

https://www.opennet.ru/base/sys/ulimit_mc.txt.html

zram,uksm cgroups- swappines, limitbytes....

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

А твой сервер от этого как-то страдает или ты пытаешься чинить то, что не сломано?

Ну можешь просто запускать их с малым приоритетом, чтобы они остальному не мешали в системе.

ulimit -m 48000 # Ограничиваем максимальный размер резидентной части процесса (находящейся в ОЗУ) в 48 MB — из статьи по ссылке выше.

Я сильно сомневаюсь, что Curl’у активно нужно столько памяти. Если это объём виртуальной памяти, то непонятно, в чём проблема вообще. Виртуальная память виртуальна.

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

https://unix.stackexchange.com/questions/44985/limit-memory-usage-for-a-singl...

https://ss64.com/bash/ulimit.html

https://ss64.com/bash/limits.conf.html

man curl на предмет --range

На размере процесса не сказалось

Это действует после логина.

ulimit -m

Оно ж на линуксе ничего не делает.

В смысле?

Требуется постоянно грепать информацию с сети

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

Чего уж проще - получать курлом чанками заданного размера?

В смысле?

Примерно так: https://cs.pikabu.ru/images/big_size_comm/2012-02_3/13291459598369.jpg

Я не нашёл в bash’е место, где обрабатывался бы этот ключ. Остальные вижу. Этот — нет.

Ну вот, опять пошло разрушение любителей зачётных ключиков и твиков реестра.

Оно BSD-специфично, в POSIX не определено, в Linux было только до 2.4.30.

Посмотри massif'ом, куда именно утекает память - скорее всего баг на твоей стороне

Значит плохо искал. Там тупо дергается setrlimit с RLIMIT_RSS. Но оно естественно не будет делать того, что хочет ТС, процесс просто грохнется, или в лучшем случае перестанет что-либо качать

а каждый запрос «кушает» весьма прилично - 158 мб RAM

158 — это VSZ, RSS или PSS?

Пересобери курл с polarssl например

Попробуй wget, aria2.

Ещё можно выучить Perl или готовый однострочник загуглить

Curl сам по себе прожорлив. Ищи альтернативу.

2 мегабайта от силы. Может буферы потюнить? Почему никто не задаётся вопросом НА ЧТО ушла память?

Разумеется, виртуальная

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
23635 alex      20   0  186648   9180   7932 S   8.3  0.1   0:04.65 curl

Памяти на сервере совсем не много и к такой объем ресурсов для такой простой операции видится избыточным.

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

Я не виноват! Они спрятали логику в таблицы, чтобы ввести меня в заблуждение.

ботоводы должны страдать :)

Букеров парсишь? Тебя найдут быстро и посадят на бидон.

Дык это VIRT, а RES всего 9190к

там в /proc/<pid>/smaps можно найти несколько кусков по 64Мб отмапленных в никуда.

Ну а я что написал? Слово «разумеется» не всегда обозначает сарказм - иногда это просто согласие с собеседником :).

Я по-моему собирал хелловорлд с libcurl, там хорошо так меньше мегабайта RES был, емнип. Вызывался в кроне, мне не понравилось что приложение curl так долго запускалось и жрало столько памяти. На самом деле у меня там пароли плейнтекстом были, это ещё одна из причин была.

Если нет тредов, то нет адской разницы VSZ/RSS

Проблема в glibc и в тредах на x86_64. На x86 такой ситуации нет.

Но x86 закапывают все кто может, начиная со сломанного PAE в 4.14

процесс просто грохнется, или в лучшем случае перестанет что-либо качать

$ grep -R RLIMIT_RSS
include/uapi/asm-generic/resource.h:#ifndef RLIMIT_RSS
include/uapi/asm-generic/resource.h:# define RLIMIT_RSS		5	/* max resident set size */
include/asm-generic/resource.h:	[RLIMIT_RSS]		= {  RLIM_INFINITY,  RLIM_INFINITY },	\
arch/mips/include/uapi/asm/resource.h:#define RLIMIT_RSS		7	/* max resident set size */
fs/proc/array.c:		rsslim = ACCESS_ONCE(sig->rlim[RLIMIT_RSS].rlim_cur);
fs/proc/base.c:	[RLIMIT_RSS] = {"Max resident set", "bytes"},

Не похоже, чтобы этот параметр хоть на что-то влиял.

На практике он, однако, работает. Я так провоцировал std::bad_alloc исключение в коде

А ты точно RLIMIT_RSS с RLIMIT_AS не путаешь?

Я сейчас сделал ulimit -m 32, что должно ограничить объём резидентной памяти до 32 килобайт. Но выжирающая память тестовая программа как кушала гиг, так и продолжает успешно кушать. /usr/bin/time говорит: «(0avgtext+0avgdata 1053972maxresident)k». С ulimit -v в определённый момент malloc() возвращает NULL.

Теперь уже не уверен

олсо, zram еще не предлагали?

Что за букеры? Зачем их парсить?

https://daniel.haxx.se/blog/2019/05/11/tiny-curl/

На сокетах накатать можно просто же. Вполне возможно что там у него не используется что-то прям такое требующие дояига кода или сторонних библиотек.