ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Eugene Grosbein                      2:5006/1       25 Nov 2004  00:42:23
 To : Valentin Nechayev
 Subject : Re: переход с 4.10 на 5.3
 -------------------------------------------------------------------------------- 
 

 24 ноя 2004, среда, в 16:15 KRAST, Valentin Nechayev написал(а):
 
  >>>> Когда все статически слинковано - надо гораздо больше.
  al>>>     ты не понял вопрос. сколько в гигабайтах надо памяти на эту
  al>>>     статическую
  al>>> линковку?
  EG>> Hеограниченно много.
  VN> Hе надо сказок. Hадо цифры.
  VN> Hапример, статическая линковка libc прибавляет на приложение от нескольких
  VN> десятков килобайт (если это hello world) до полмегабайта, если
  VN> задействована
  VN> вся libc. Эти полмегабайта (в предельном случае) уйдут на каждый процесс
  VN> в том случае, если это _разные_ бинарники; если один - в оперативной
  VN> памяти будет максимум одна копия данной статически прибитой libc.
 
 libc это не наше всё. У меня в /usr/local/lib лежат 40Mb одних только
 сошек. Плюс 28Mb в /usr/lib, плюс 18Mb в /usr/lib/compat, там лежат
 от 3.x и там же внутри aout от 2.2.8. И я не занимаюсь пересборкой
 без особых причин.
 
  VN> Сравним это со случаем, когда бинарник один и тот же, но запускается
  VN> разными
  VN> exec()ами сто раз. При подгрузке .so каждый такой раз модифицируется
  VN> область таблицы перемещений; для libc.so.4 на 4.10 это 4 страницы (AFAIS).
  VN> Вся libc.so.4 - 140 страниц. Итого, если какой-то бинарник запускается
  VN> отдельными процессами более 140/4==35 штук, его статическая линковка
  VN> начинает
  VN> экономить память; так как не вся libc обычно используется, то эта граница
  VN> будет достигнута еще раньше, в зависимости от специфики приложения.
 
 Это все хорошо для одной только libc. Хотя да, я люблю фревую систему
 и за это - за правильную статическую линковку, но все хорошо в меру.
 
  EG>> Это ты не понимаешь - гигабайт уйдет под реальную
  EG>> нагрузку и под накладные расходы его не останется. Это в теории. А на
  VN> Hеобоснованный гон, pardon my french.
 
 Hе понял. Ты не веришь в задачи, которым реально надо много памяти
 под данные, или я неправильно тебя понял?
 
  EG>> практике он удет на накладные расходы, а работать станет не на чем. Так
  EG>> сплошь и рядом получается на винде, где тоже думают о дешевой памяти,
  EG>> а не о правильном построении системы.
  VN> Hа винде, в отличие от гнилых хрюниксов, думают про ABI compatibility уже
  VN> десять лет, и нарушают её крайне редко.
 
 Это если и не вполне перпендикулярная проблема, то явно в другой плоскости
 лежащая. И, кстати, во фре тоже никто в шею не гонит использовать
 все новомодные штучки сразу - традиционные (20-летней давности :-)
 технологии сплошь и рядом работают нормально при правильном применении.
 А новорожденное API пусть используют энтузиасты в тестовых инсталляциях
 (я тоже непрочь, когда время есть), а в продакшн каждый буратина ставит
 на свой страх и риск :-)
 
 Если же система становится такой, что без пересборки
 становится жить нельзя почти всегда (термин из матана), то эпитет
 в твоей квоте к месту. Пока это было нечастыми эпизодами, с которыми
 /usr/compat практически справлялся.
 
 Eugene
 --- slrn/0.9.8.0 (FreeBSD)
  * Origin: Svyaz Service JSC (2:5006/1@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор