Мультипоточная компиляция приводит к зависанию компьютера

antlord

# 7 лет, 7 месяцев назад

Темы: 30 Сообщения: 195 Участник с: 24 июня 2012

Добрый день! Наткнулся на проблему связанную с мультипоточной копиляцией через make. Точнее я и раньше ее видел, но решил после ключа -j указывать n-1 потоков, где n — количество потоков, поддерживаемое процессором. Недавно заметил, что мой товарищ собирает проекты, используя все потоки. Он сказал, что не настраивал компьютер по-особенному. На ноутбуках у нас стоят одинаковые 4-х поточные core i5. На тот момент у него было столько же оперативной памяти, сколько и у меня. И проверял я на одном и том же проекте. Я пробовал также на других компьютерах запускать. Стационарный компьютер с процессором AMD FX-6300 (6 ядер) тоже виснет. На ноутбуке с i3 таже самая проблема. Если кто знает, что надо сделать, что машина не зависала при использовании всех потоков, подскажите пожалуйста что искать надо хотя бы. Заранее спасибо!

jim945	# 7 лет, 7 месяцев назад
Темы: 8 Сообщения: 3066 Участник с: 25 января 2010	Что значит виснет? Ничего не висло никогда из-за этого. Проблема в чем-то другом. Что компилируешь-то? Lupus pilum mutat, non mentem.

antlord	# 7 лет, 7 месяцев назад
Темы: 30 Сообщения: 195 Участник с: 24 июня 2012	Виснет, значит комп ни на что не реагирует и изображение на мониторе не изменяется. Проект на Ogre компилируем. Но если собирать какой-нибудь boost, то компьютер может тоже зависнуть.

sirocco	# 7 лет, 7 месяцев назад
Темы: 29 Сообщения: 2501 Участник с: 25 июля 2007	antlord Недавно заметил, что мой товарищ собирает проекты, используя все потоки. Он сказал, что не настраивал компьютер по-особенному. На ноутбуках у нас стоят одинаковые 4-х поточные core i5. ОС какие?

antlord	# 7 лет, 7 месяцев назад
Темы: 30 Сообщения: 195 Участник с: 24 июня 2012	Эмм. Arch Linux везде

marlock	# 7 лет, 7 месяцев назад
Темы: 35 Сообщения: 736 Участник с: 02 июля 2010	Оперативная память заканчивается, я думаю. Закрыть всякие гуглохромы, жрущие память, и пробовать ещё. Для сборки chromium год назад нужно было около 3.5 гигабайт оперативной памяти, а у меня всего 4, тоже зависало.

sirocco	# 7 лет, 7 месяцев назад (отредактировано 7 лет, 7 месяцев назад)
Темы: 29 Сообщения: 2501 Участник с: 25 июля 2007	antlord Эмм. Arch Linux везде Может у товарища SSD? Можно пробовать nice + ionice, может быть поможет. (и/или zram/zswap) (Когда-то очень давно собирал firefox-pgo на нетбуке, подобные тормоза были только при линковке).

jim945	# 7 лет, 7 месяцев назад
Темы: 8 Сообщения: 3066 Участник с: 25 января 2010	sirocco Может у товарища SSD? А как это может влиять? Нет я понимаю скорость выше в сравнении с hdd. Взял за правило компилировать все в /tmp, который в оперативке. И скорость hdd не влияет, и ssd не протирается. marlock Оперативная память заканчивается, я думаю. Вот это кстати вполне вероятно. Уже забыл, что это такое, с нынешними объемами оперативки. Lupus pilum mutat, non mentem.

Natrio

# 7 лет, 7 месяцев назад

Темы: 47 Сообщения: 4763 Участник с: 08 января 2011

Не просто память заканчивается, а заканчивается при отсутствии свапа, как я понимаю. Или вместе со свапом, если он маленький. Такое очень может быть, если забивать память массированной записью в tmpfs, я уже рассказывал. Так что если места в /tmp не хватает, выходов два: 1) перенести компиляцию в другое место; 2) расширить объём tmpfs за счёт увеличения её доли в памяти, с подключением значительных размеров свапа.

jim945

# 7 лет, 7 месяцев назад

Темы: 8 Сообщения: 3066 Участник с: 25 января 2010

Natrio если забивать память массированной записью в tmpfs Кстати. Сколько под нее выделяется поумолчанию? И где это прописано? Natrio 2) расширить объём tmpfs за счёт увеличения её доли в памяти, с подключением значительных размеров свапа. Тогда памяти для компиляции, особенно многопоточной, будет меньше. Соответственно большие тормоза в случае с HDD. Первый вариант лучше. Lupus pilum mutat, non mentem.