А в памяти моей такая скрыта мощь...

[Palych]

По моим многолетним (хоть и ограниченным) наблюдениям я практически никогда не видел чтобы при планировании, дизайне систем учитывался расход памяти.
Экономим время разработки, стоимость сопровождения, на худой конец CPU time, но не стоимость памяти.
Например: добавить "слой" веб сервисов, который принимают запросы от других сервисов и перебрасывают далее по инстанциям - нет проблем...
Или кэш: все что читаем из базы или иного внешнего ресурса - отбросим в кеш, авось пригодится. Или вообще - загрузим в память заранее (in memory storage...)
Martin Fowler говорил о cache invalidation, как одной из главных проблем CS.
А о том что насколько реально этот кеш помогает, какой процент записей читается из кеша - как-то редко думают...

Но я уже много лет живу под камнем, трендов не улавливаю.
Мне интересно как в современных системах с этим обстоит дела?
Особенно в облаках: сколько можно сэкономить "в масштабах страны" если хотя бы отчасти пытаться расходовать память не совсем безумно?
Есть ли сейчас тренд на экономию памяти?

[tessob]

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

[OtherSide]

В каких нибуть встроенных системах имеет смысл, а так память стоит копейки или ее все равно пользователь покупает, какой смысл?
Нужно понимать, что основная цель прогресса в IT = уменьшить стоимость разработки ПО

[Dmitry67]

Если вы в пещере на мейнфреме, то придется память экономить

[Palych]

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

Кажется понятно...

[Flash-04]

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

[Palych]

И для облаков это не проблема?
Когда куча VM на одном сервере - разве память не становится более критичным ресурсом?
Например - участвует ли ли объём памяти в ценообразовании? Или только время работы?

[Flash-04]

Становится. VM по разному стоят.

[mikeG]

В embedded приложениях всегда бюджет памяти специфицируется на все.
В облаках response time обычно важен, а сколько оно памяти там жрет в какой-то виртуалке - какая нафиг разница. Начнет падать - добавят памяти.

[Slonjra]

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

каждое утро начинаю с того, что прибиваю пару процессов Файрфокса, который умудряется в спящем режиме сожрать всю доступную память ))))))
и ведь куча лет этой софтине, а с памятью так и не научилась работать )))

[Palych]

В embedded приложениях всегда бюджет памяти специфицируется на все.
В облаках response time обычно важен, а сколько оно памяти там жрет в какой-то виртуалке - какая нафиг разница. Начнет падать - добавят памяти.

То есть - устойчивый консенсус в том, что память всегда можно взять из тумбочки, и добавить?

[mskmel]

То есть - устойчивый консенсус в том, что память всегда можно взять из тумбочки, и добавить?

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

[Dmitry67]

На самом деле чем больше память, тем важнее писать cache-friendly code

Например, производительность двух фрагментов кода ниже отличается в 20 раз примерно:

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[i,j];

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[j,i];

[Helmsman]

То есть - устойчивый консенсус в том, что память всегда можно взять из тумбочки, и добавить?

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

[zVlad]

Если вы в пещере на мейнфреме, то придется память экономить

Не экономить, а использовать разумно. Как впрочем и любой другой ресурс на МФ используются.
По части хранения данных БД в "кэшах" (buffer pools) DB2 представляет достаточно параметров чтобы понять насколько эффективно используется выделенная под них память. Кроме того, в зависимости от параметров, заданых в SLA, WLM совместно с DB2 способeн динамически изменять размер буферных пулов с тем чтобы обеспечить выполнение SLA.

[zVlad]

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

[Dm.uk]

В embedded приложениях всегда бюджет памяти специфицируется на все.

... скорее сперва "сколько жрет", ну а потом уже "сколько памяти" ;-)

[Palych]

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

(и когда уже на wintel виртуальную память сделают?... )
Засада в том, что приложения все данные которые читаются извне (даже с диска, который может иметь свой кеш, плюс кеш на уровне ОС) откладывают в кеш на уровне приложения (ассоциативный массив и проч.)
Таким образом для системы эта память вполне себе используемая, и отбросить её в долгий ящик невозможно.

[OtherSide]

Вы же слышали о том, что преждевременная оптимизация - зло? Так зачем экономить память пока ее все еще хватает?

[Palych]

Вы же слышали о том, что преждевременная оптимизация - зло? Так зачем экономить память пока ее все еще хватает?

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

[Palych]

oops

[zVlad]

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

(и когда уже на wintel виртуальную память сделают?... )
Засада в том, что приложения все данные которые читаются извне (даже с диска, который может иметь свой кеш, плюс кеш на уровне ОС) откладывают в кеш на уровне приложения (ассоциативный массив и проч.)
Таким образом для системы эта память вполне себе используемая, и отбросить её в долгий ящик невозможно.

Я не говорил что на wintel нет виртуальной памяти.....

[mskmel]

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

А также разные connection pools, service listeners, etc.

[Palych]

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

(и когда уже на wintel виртуальную память сделают?... )
Засада в том, что приложения все данные которые читаются извне (даже с диска, который может иметь свой кеш, плюс кеш на уровне ОС) откладывают в кеш на уровне приложения (ассоциативный массив и проч.)
Таким образом для системы эта память вполне себе используемая, и отбросить её в долгий ящик невозможно.

Я не говорил что на wintel нет виртуальной памяти.....

Извиняюсь, не догнал.
То есть - если данные кешируются, но кеш не используется - эти данные в итоге упадут в своп?
Я не спец во внутреннем устройстве современных систем, типа JVM.
Но на основании простого житейского опыта предположу что даже теоретически никуда эти данные не выпадут.
Прошу поправить мои доводы тех кто в теме:
1. На уровне ОС память распределяется/свопится страницами. JVM управляет объектами, которые неизбежно раскидываются между страницами.
2. Объекты в JVM постоянно "дергаются" сборщиком мусора.

[fleshold]

На самом деле чем больше память, тем важнее писать cache-friendly code

Например, производительность двух фрагментов кода ниже отличается в 20 раз примерно:

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[i,j];

Code: Select all

int sum = 0;
for (int i=0; i<10000; i++)
  for (int j=0; j<10000; j++)
    sum += A[j,i];

Ну точно не в 20, а наверное раза в полтора, ну может в 2. A[i,j]? Что за языг?