Как сказал @bnaecker, это не простой ответ (то есть да / нет). Проблема заключается только в том, что объединенный RSS (размер резидентного набора) всех запущенных процессов превышает доступную память, что вызывает чрезмерное использование страниц подкачки.
Вы не сказали, как рассчитывали размер каждого объекта. Надеюсь, это было с помощью sys.getsizeof()
, который должен точно включать издержки, связанные с каждым объектом. Если вы использовали какой-то другой метод (например, вызов метода __sizeof()
напрямую), тогда ваш ответ будет намного ниже правильного значения. Однако даже sys.getsizeof()
не будет учитывать потерянное пространство из-за выравнивания памяти. Например, рассмотрим этот эксперимент (используя python 3.6 в macOS):
In [25]: x='x'*8193
In [26]: sys.getsizeof(x)
Out[26]: 8242
In [28]: 8242/4
Out[28]: 2060.5
Обратите внимание на последнее значение. Это означает, что объект использует 2060 и 1/2 слова памяти. Что неверно, так как все выделения потребляют кратные слова. На самом деле, мне кажется, что sys.getsizeof()
неправильно учитывает выравнивание и заполнение слов либо базового объекта, либо структуры данных, которая описывает этот объект. Это означает, что значение меньше объема памяти, фактически используемого объектом. Умножается на 100 000 объектов, которые могут представлять значительный объем памяти.
Кроме того, многие распределители памяти округляют большие выделения до размера страницы (обычно кратного 4 КиБ). Что приводит к «потраченному впустую» пространству, которое, вероятно, не будет включено в возвращаемое значение sys.getsizeof()
.