LINUX.ORG.RU
решено Форум — General  

Прога занимает ОЗУ в несколько раз больше, чем занимает диска

 ,


0

1

Скажу сразу, что гуглить пытался - ничего не нашёл, а что нашёл, то ссылалось на фоновую малварь. Есть «Удалятор мусора», написанный на Go. Исходник занимает 3.4 килобайта, а собранный линуксовый бинарник с отключённой отладкой и дебагом - примерно 1.7 мегабайт. Запуская удалятор, он сразу же забирает 5-6 мегабайт оперативы, а при запуске поиска файлов потребление скачком растёт с 11 до 16 мегабайт. С чем связано такое лютое потребление? Скачок при поиске может быть вызван подгрузкой библиотеки?

★
← openwrt ipv6
Плохой звук на ноутбуке Asus ROG zephyrus g14 на любом дистре Linux →
 ← 1 2 3
Ответ на: комментарий от vbcnthfkmnth123

Мб так какая-то функция рекурсивно вызывается?

Не похоже. Тут все функции вызываются по порядку

func main() {
	admcheck()
	choosemode()
	switch mode {
	case 1:
		fmt.Println("Кого мы ищем сегодня?")
		fmt.Scanln(&current_target)
		fmt.Println("Тогда, наша цель -", current_target)

	case 2:
		fmt.Println("В вашем раяпоряжении находится массив, в который можно загнать до трёх различных файлов. Кого мы ищем сегодня?")
		for i := range target_array {
			fmt.Scanln(&target_array[i])
		}
		fmt.Println("Тогда, наши цели -", target_array)
	}
	filecheck()

}

, где скачок появляется именно на моменте filecheck(), который вызывает обработчик ошибок внутри search(), который вызывает саму функцию поиска и высасывает с неё ошибки

func search() {
	err := findAndDelete(current_target, "/") // ищем в текущей директории
	if err != nil {
		fmt.Println("Ошибка:", err)
		return
	}
}
Tyse_EX ★
() автор топика
Последнее исправление: Tyse_EX (всего исправлений: 1)

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

16 мегабайт
лютое потребление

кек

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

Нет.

У меня прога на С++ имеет бинарник 280 КБ, а оперативки при работе потребляет до 40-50 МБ. Потому что при сканировании файлов создаёт сложную структуру данных с сотнями тысяч записей.

anonymous
()
Ответ на: комментарий от Tyse_EX 
#include <stdlib.h>

int main() {
  for (;;) {
    malloc(8192);
  }
  return 0;
}

Если скомпилировать эту программу, то она занимает 16 Кб (можно, наверное, и меньше ужать, но лень).

Попробуй оценить, сколько она займёт оперативной памяти.

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

Что будет загружаться в память - полностью зависит от логики программы.

Твоя мысль очевидна, но если подумать, то понятно, что это неразумно. Представь большую сложную программу с уймой функций и опций. Хорошо ли всё это грузить в память, когда пользователь командует program --help?

anonymous
()

Не смотрел на теги, ожидал тут увидеть шок от лицезрения электроноподелий. А 16мб это ерунда. Сам бинарник, стек, данные, mmap, везде аллокация с запасом, вот и набирается.

legolegs ★★★★★
()

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

десятки мегабайт - это обычное дело.

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

alysnix ★★★
()

Удивительно, сама программа занимает больше места в оперативной памяти, чем на диске!!!

У меня похожая проблема, кстати, Telegram на телефоне — апк 60 МБ, а потом 3 ГБ кэша, 400 стикеров, 50 чатов и папка с мемами за 2018. Мало весит, но как заживёт в ОЗУ — хоть отдельную комнату выделяй.

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

У меня похожая проблема, кстати, Telegram на телефоне — апк 60 МБ, а потом 3 ГБ кэша, 400 стикеров, 50 чатов и папка с мемами за 2018. Мало весит, но как заживёт в ОЗУ — хоть отдельную комнату выделяй.

Старый Мазай разболтался в сарае.
В этом болотистом низменнном крае толстых программ не счесть …

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

Если проблема возникла не из-за ЯП, тогда из-за кого? В какой момент единица становится парой? Чьей метафизической сущности присуще принять одно, а отдать два? Может это чистая воля? Воля, которая меняет сущее, но остаётся в тени, свободная от желаний, цели и средств, необъяснимая как инстинкт, неосязаемая как ложь и неизбежная как данность?

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

Можешь форкбомбу скомпилять, она тебе бинарником в килобайты позволит всю оперативку и своп съесть.

Поищи, как процесс выполнения обычной программы работает.

Bfgeshka ★★★★★
()

Какое же это лютое потребление? Речь про несколько мегабайт. Это ты ещё поделок на говно-электроне не видел, где «Hello, world» - из коробки жрёт сотни мегабайт места, памяти и т.д. А тут такая ерунда, никто даже не заметит :)

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

Я зашёл суда спросить, не написана ли прога на Go, а оказалось, она написана на Go. У меня нет больше вопросов.

Так глупость вопроса топикстартера никак не связана с выбранным ЯП. Ну написал ты на сях в три строчки херню, которая читает в переменную любой файл, а потом скормил этой проге гиговый лог.

И обоже, прога весит 2Кб, а оперативы сожрала гигабайт - как же так вышло и

С чем связано такое лютое потребление?

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

Проблема ведь не только в том, выгружается сама программа или нет, а в том, что обычно программы не в вакууме существуют, а оперируют какими-то внешними данными и как раз эти данные основную часть потребления ОЗУ и составляют

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

что то типа такого:

section .text
global _start

_start:
    ; Выделяем память с помощью sys_brk
    mov rax, 12         ; sys_brk
    xor rdi, rdi        ; запросить текущий break
    syscall
    
    mov r15, rax        ; сохраняем текущий break в r15
    
.loop:
    ; Увеличиваем break на 1 страницу (4096 байт)
    mov rax, 12         ; sys_brk
    mov rdi, r15
    add rdi, 4096       ; увеличиваем на размер страницы
    syscall
    
    mov r15, rax        ; сохраняем новый break
    
    ; Записываем что-то в новую память (чтобы страницы действительно выделились)
    mov byte [rax - 4096], 0
    
    ; Повторяем бесконечно
    jmp .loop
Silerus ★★★★★
()

Я совсем не профи в теме линуксовых памятей, но давно заметил, что софт на go делает непонятное (для меня) с этой самой памятью. Присуще всему, что у меня есть\было на Go: traefik, caddy, yggdrasil, у них в VIRT меньше 1.2GB не бывает, даже и на виртуалках с 512МБ памяти, и даже на Фряхе.

Да, это VIRT, а не RES. Может это и вовсе дичь и VIRT репортит откровенную чушь, т.к. на некотором софте там показано и 30гиг, и 563гига и 1.4ТБ я как-то видел (что-то на Электроне).

kixx09
()
Последнее исправление: kixx09 (всего исправлений: 1)
 ← 1 2 3
← openwrt ipv6
General
Плохой звук на ноутбуке Asus ROG zephyrus g14 на любом дистре Linux →