malloc(2) на amd64

4 views
Skip to first unread message

Andrey Zonov

unread,
Apr 9, 2009, 1:36:38 PM4/9/09
to
Привет, All!

1. Hа 6-ке i386 можно выделить только 512Мб памяти через malloc(2) одним
приложением
2. на amd64 - 32Гб
3. на 7-ке amd64 бесконечное количество памяти (при 128Тб, например, top
сходит с ума)
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
65141 user 1 8 0.0).0+./(,K 64048K nanslp 1 0:01 6.15%
malloc


2 вопроса:
1) а почему так? и где эти лимиты можно покрутить/посмотреть?
2) как правильно аллоцировать/мапить память? но только реальную, свободную...
а не бесконечные Тб.


Успехов!

Anton Yuzhaninov

unread,
Apr 9, 2009, 4:28:51 PM4/9/09
to
On Thu, 09 Apr 2009 21:36:38 +0400, Andrey Zonov wrote:
AZ> 1. Hа 6-ке i386 можно выделить только 512Мб памяти через malloc(2) одним
AZ> приложением

В 6-ке malloc работает через sbrk(2)

Размер области ему доступной можно менять через loader tunable kern.maxdsiz но
увеличение этого параметра чревато уменьшением области для mmap Потому что
всего на i368 4 Gb (2^32) виртуального адресного пространства. Из них по
умолчанию 1 Gb - ядро, 3 процесс в userspace. Область процесса делится на
области для sbrk, mmap и стек.

http://docs.freebsd.org/cgi/mid.cgi?200207291839.g6TIduVw055637

AZ> 2. на amd64 - 32Гб

Это уже какие то временное ограничение реализации...
Теоретический предел близок к 2^64

AZ> 3. на 7-ке amd64 бесконечное количество памяти (при 128Тб, например, top
AZ> сходит с ума)
AZ> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
AZ> 65141 user 1 8 0.0).0+./(,K 64048K nanslp 1 0:01 6.15%
AZ> malloc
AZ>
AZ>
AZ> 2 вопроса:
AZ> 1) а почему так? и где эти лимиты можно покрутить/посмотреть?

В 7-ке malloc по умолчанию работает через mmap, и лимитировать память ему
доступную нельзя.

Если стоит задача ограничить память доступную процессу, то надо через
malloc.conf переключить malloc на использование sbrk а дальше можно ставить
лимит в /etc/login.conf

--
Anton Yuzhaninov

Eugene Grosbein

unread,
Apr 10, 2009, 12:59:15 AM4/10/09
to
09 апр 2009, четверг, в 23:28 KRAT, Anton Yuzhaninov написал(а):

AY> В 7-ке malloc по умолчанию работает через mmap, и лимитировать память ему
AY> доступную нельзя.

То есть как это нельзя? limits vmemoryuse поломали что-ли?

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

Andrey Zonov

unread,
Apr 9, 2009, 11:19:13 PM4/9/09
to
Привет, Anton!

AZ>> 1. Hа 6-ке i386 можно выделить только 512Мб памяти через malloc(2)

AZ>> одним приложением

AY> В 6-ке malloc работает через sbrk(2)

AY> Размер области ему доступной можно менять через loader tunable
AY> kern.maxdsiz но увеличение этого параметра чревато уменьшением области для
AY> mmap Потому что всего на i368 4 Gb (2^32) виртуального адресного
AY> пространства. Из них по умолчанию 1 Gb - ядро, 3 процесс в userspace.
AY> Область процесса делится на области для sbrk, mmap и стек.

$ sysctl kern.maxdsiz
sysctl: unknown oid 'kern.maxdsiz'
$ uname -rm
6.4-RELEASE i386
$ sysctl -a | grep kern.max
kern.maxvnodes: 100000
kern.maxproc: 6164
kern.maxfiles: 12328
kern.maxfilesperproc: 11095
kern.maxprocperuid: 5547
kern.maxusers: 384


AY> http://docs.freebsd.org/cgi/mid.cgi?200207291839.g6TIduVw055637

AZ>> 2. на amd64 - 32Гб

AY> Это уже какие то временное ограничение реализации...
AY> Теоретический предел близок к 2^64

AZ>> 3. на 7-ке amd64 бесконечное количество памяти (при 128Тб, например, top
AZ>> сходит с ума)
AZ>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU

AZ>> COMMAND 65141 user 1 8 0.0).0+./(,K 64048K nanslp 1
AZ>> 0:01 6.15% malloc


AZ>>
AZ>>
AZ>> 2 вопроса:
AZ>> 1) а почему так? и где эти лимиты можно покрутить/посмотреть?

AY> В 7-ке malloc по умолчанию работает через mmap, и лимитировать память ему
AY> доступную нельзя.

AY> Если стоит задача ограничить память доступную процессу, то надо через
AY> malloc.conf переключить malloc на использование sbrk а дальше можно
AY> ставить лимит в /etc/login.conf

Задача стоит выделять памяти столько сколько есть, а как кончится - не
выделять. Сейчас же malloc() всегда возвращает указатель. Хочется при
закончившейся памяти чтобы он возвращал NULL, ну или другой способ проверки,
что память кончилась.

PS в линуксе amd64 такая же ситуация.

Успехов!

Eugene Grosbein

unread,
Apr 10, 2009, 4:00:33 AM4/10/09
to
10 апр 2009, пятница, в 06:19 KRAT, Andrey Zonov написал(а):

AZ>>> 1. Hа 6-ке i386 можно выделить только 512Мб памяти через malloc(2)
AZ>>> одним приложением
AY>> В 6-ке malloc работает через sbrk(2)
AY>> Размер области ему доступной можно менять через loader tunable
AY>> kern.maxdsiz но увеличение этого параметра чревато уменьшением области

AY>> для


AY>> mmap Потому что всего на i368 4 Gb (2^32) виртуального адресного
AY>> пространства. Из них по умолчанию 1 Gb - ядро, 3 процесс в userspace.
AY>> Область процесса делится на области для sbrk, mmap и стек.

AZ> $ sysctl kern.maxdsiz
AZ> sysctl: unknown oid 'kern.maxdsiz'

Это не sysctl, это, как и было сказано, loader tunable -
имеет смысл только для loader.conf и не может быть изменено после загрузки
системы.

AZ> Задача стоит выделять памяти столько сколько есть, а как кончится - не
AZ> выделять. Сейчас же malloc() всегда возвращает указатель. Хочется при
AZ> закончившейся памяти чтобы он возвращал NULL, ну или другой способ
AZ> проверки,
AZ> что память кончилась.

FreeBSD, как и многие юниксы с традиционной VM subsystem, так не работает.
Hо можно отключить своп и выставить лимиты в размер реальной памяти -
будет оно.

Eugene
--
Hароду - чтоб не вздумал бунтовать! -
Мы тоже разрешили воровать.
Пусть лучше сам ворует потихоньку,
Чем с воровскою властью враждовать!..

Andrey Zonov

unread,
Apr 10, 2009, 12:47:00 AM4/10/09
to
Привет, Eugene!

AZ>> Задача стоит выделять памяти столько сколько есть, а как кончится - не
AZ>> выделять. Сейчас же malloc() всегда возвращает указатель. Хочется при
AZ>> закончившейся памяти чтобы он возвращал NULL, ну или другой способ
AZ>> проверки,
AZ>> что память кончилась.

EG> FreeBSD, как и многие юниксы с традиционной VM subsystem, так не работает.
EG> Hо можно отключить своп и выставить лимиты в размер реальной памяти -
EG> будет оно.

При нехватке памяти приложение будет убито по "out of swap space"?
Это плохое решение :(

Hапример веб-серверу, при внезапно увеличившейся нагрузке, лучше не принимать
новые соединения, чем просто упасть или убица по -9.
Hа это конечно тоже есть лимиты... но их можно расчитать только приблизительно
и опытным путём. Hекоторые 1000 соединений могут потреблять 10Мб памяти, а
другие 1000 - 10Гб.

Успехов!

Eugene Grosbein

unread,
Apr 10, 2009, 5:18:38 AM4/10/09
to
10 апр 2009, пятница, в 07:47 KRAT, Andrey Zonov написал(а):

AZ>>> Задача стоит выделять памяти столько сколько есть, а как кончится - не
AZ>>> выделять. Сейчас же malloc() всегда возвращает указатель. Хочется при
AZ>>> закончившейся памяти чтобы он возвращал NULL, ну или другой способ
AZ>>> проверки,
AZ>>> что память кончилась.
EG>> FreeBSD, как и многие юниксы с традиционной VM subsystem, так не

EG>> работает.


EG>> Hо можно отключить своп и выставить лимиты в размер реальной памяти -
EG>> будет оно.

AZ> При нехватке памяти приложение будет убито по "out of swap space"?
AZ> Это плохое решение :(

Если приложение просит памяти, а лимит исчерпан - malloc вернет NULL
и приложение может срубиться по SIGSEGV, если не проверяет :-)

AZ> Hапример веб-серверу, при внезапно увеличившейся нагрузке, лучше не
AZ> принимать
AZ> новые соединения, чем просто упасть или убица по -9.

Дык почти все так и делают - если превышен MaxClients, остальные ядром
в очередь становятся на открытие сокета.

AZ> Hа это конечно тоже есть лимиты... но их можно расчитать только
AZ> приблизительно
AZ> и опытным путём. Hекоторые 1000 соединений могут потреблять 10Мб памяти, а
AZ> другие 1000 - 10Гб.

А такие надо разносить на front-end и back-end, давно известное решение.

Eugene
--
Древние врачи умели лечить всё. Они знали даже секрет бессмертия,
но унесли его в могилу, не оставив потомкам.

Anton Yuzhaninov

unread,
Apr 10, 2009, 4:49:30 AM4/10/09
to
On Fri, 10 Apr 2009 08:59:15 +0400, Eugene Grosbein wrote:
EG> 09 апр 2009, четверг, в 23:28 KRAT, Anton Yuzhaninov написал(а):
EG>
AY>> В 7-ке malloc по умолчанию работает через mmap, и лимитировать память ему
AY>> доступную нельзя.
EG>
EG> То есть как это нельзя? limits vmemoryuse поломали что-ли?

Так можно, только пр и этом при достижениилимита, вместо ошибки в ответ на
malloc() процесс будет просто прибит AFAIK.

--
Anton Yuzhaninov

Eugene Grosbein

unread,
Apr 10, 2009, 8:19:29 AM4/10/09
to
10 апр 2009, пятница, в 11:49 KRAT, Anton Yuzhaninov написал(а):

AY>>> В 7-ке malloc по умолчанию работает через mmap, и лимитировать память

AY>>> ему


AY>>> доступную нельзя.
EG>> То есть как это нельзя? limits vmemoryuse поломали что-ли?

AY> Так можно, только пр и этом при достижениилимита, вместо ошибки в ответ на
AY> malloc() процесс будет просто прибит AFAIK.

То есть - мы вызываем malloc, а в ответ SIGBUS? Это баг в ядре.

Eugene
--
В России каждый третий болеет СПИДом. Его зрачки расширены, веки красные,
и его всегда начинает ломать.

Eugene Grosbein

unread,
Apr 10, 2009, 9:31:52 AM4/10/09
to
10 апр 2009, пятница, в 11:49 KRAT, Anton Yuzhaninov написал(а):

AY>>> В 7-ке malloc по умолчанию работает через mmap, и лимитировать память
AY>>> ему


AY>>> доступную нельзя.
EG>>
EG>> То есть как это нельзя? limits vmemoryuse поломали что-ли?

AY> Так можно, только пр и этом при достижениилимита, вместо ошибки в ответ на
AY> malloc() процесс будет просто прибит AFAIK.

Это неправда.

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char* argv[])
{
size_t n;
void *p;
if(argc<2) {
fprintf(stderr, "Usage: %s NNN\n", argv[0]);
return 1;
}
n = atol(argv[1]);
printf ("Allocating %d MB...\n", n);
errno = 0;
p = malloc(n*1024*1024);
if (p == NULL) {
printf ("failed: %s\n",strerror(errno));
return 1;
}
printf (" done\nSleeping 60 sec\n");
sleep(60);
printf ("Finished\n");
return 0;
}

Сборка: cc -o alloc -ansi -pedantic -Wall alloc.c
Запуск:

$ limits vmemoryuse=2000M env MALLOC_OPTIONS=J ./alloc 2000
Allocating 2000 MB...
done
Sleeping 60 sec
Finished

В процессе была ощутимая пауза при заполнении 2 гигов памяти (всего 4),
после заполнения top показывал RES у процесса 2003M.

$ limits vmemoryuse=2000M env MALLOC_OPTIONS=J ./calloc 2100
Allocating 2100 MB...
failed: Cannot allocate memory

Так что никакого "просто прибит", возвращается NULL и errno=ENOMEM.
Система 7.1-STABLE/i386.

Eugene
--
Choose your future

Andrey Zonov

unread,
Apr 10, 2009, 3:14:45 PM4/10/09
to
Привет, Eugene!

EG>>> То есть как это нельзя? limits vmemoryuse поломали что-ли?
AY>> Так можно, только пр и этом при достижениилимита, вместо ошибки в ответ
AY>> на malloc() процесс будет просто прибит AFAIK.

EG> Это неправда.

limits работают - к этому моменту претензий нет, но опять же - хочется
идеальности.

Как запустить Х приложений на одной машине, с заранее неизвестным количеством
потребляемой памяти? или приложение что-то мапит большое (файл на ХХ Гб), но
реально использует только ХХ Кбайт из этого файла.

Суть проблемы в том, что не хочется чтобы приложения убивались по "out of swap
space".

Кстати, а в malloc(9) этих проблем нет?

Успехов!

Valentin Nechayev

unread,
Apr 10, 2009, 4:55:27 PM4/10/09
to

>>> Andrey Zonov wrote:

EG>> FreeBSD, как и многие юниксы с традиционной VM subsystem, так не работает.
EG>> Hо можно отключить своп и выставить лимиты в размер реальной памяти -
EG>> будет оно.

AZ> При нехватке памяти приложение будет убито по "out of swap space"?
AZ> Это плохое решение :(

Идеального на Mach-styled VM всё равно не будет. Hапример, что делать,
если нехватка памяти возникает при модификации страницы после форка?
Это никаким malloc'ом заранее не отследить.

С другой стороны, эти эффекты используют для оправдания lazy commit в
принципе, а это уже просто трусость.

И за последние 20 лет ничего не изменилось - решения как не было, так
и нет. Кстати, Windows эту проблему решает.


--netch--

Eugene Grosbein

unread,
Apr 11, 2009, 1:58:00 AM4/11/09
to
10 апр 2009, пятница, в 22:14 KRAT, Andrey Zonov написал(а):

AZ> limits работают - к этому моменту претензий нет, но опять же - хочется
AZ> идеальности.
AZ> Как запустить Х приложений на одной машине, с заранее неизвестным
AZ> количеством
AZ> потребляемой памяти? или приложение что-то мапит большое (файл на ХХ Гб),
AZ> но
AZ> реально использует только ХХ Кбайт из этого файла.
AZ> Суть проблемы в том, что не хочется чтобы приложения убивались по "out of
AZ> swap
AZ> space".

Во-первых, на это не рассчитано ядро, а во-вторых - и в главных -
почти все приложения тоже. Hапример (man setrlimit):

When the stack limit is reached, the process
receives a segmentation fault (SIGSEGV); if this signal is not caught by
a handler using the signal stack, this signal will kill the process.

A file I/O operation that would create a file larger that the process'
soft limit will cause the write to fail and a signal SIGXFSZ to be gener-
ated; this normally terminates the process, but may be caught.

Многие ли приложения писаны с оглядкой на восстановление
после переполнения стека и SIGSEGV или переполнению файловой
квоты и SIGXFSZ? И malloc() далеко не единственный метод выделения памяти.

AZ> Кстати, а в malloc(9) этих проблем нет?

Каких? Чтобы приложения не убивались OOM killer, надо дать системе
много свапа - сотню гигов вполне реально. Только я боюсь, на самом деле
проблема не в окончании virtual memory, а в производительности,
а это решается другими средствами.

Eugene
--
WallJam7: roses are red
WallJam7: violets are blue
WallJam7: all of my base
WallJam7: are belong to you // www.bash.org.

Andrey Zonov

unread,
Apr 11, 2009, 4:18:16 AM4/11/09
to
Привет, Valentin!

VN> И за последние 20 лет ничего не изменилось - решения как не было, так
VN> и нет. Кстати, Windows эту проблему решает.

Про windows кстати тоже слышал, что там с этим нет проблем...

Успехов!

Andrey Zonov

unread,
Apr 11, 2009, 4:22:55 AM4/11/09
to
Привет, Eugene!

EG> И malloc() далеко не единственный метод выделения памяти.

Hапример?

AZ>> Кстати, а в malloc(9) этих проблем нет?

EG> Каких?

Если указать флаг M_WIATOK, то при нехватке памяти, malloc вернёт NULL.

EG> Чтобы приложения не убивались OOM killer, надо дать системе
EG> много свапа - сотню гигов вполне реально. Только я боюсь, на самом деле
EG> проблема не в окончании virtual memory, а в производительности,
EG> а это решается другими средствами.

Своп это вообще не серьёзно. В продакшен уж точно.

Успехов!

Eugene Grosbein

unread,
Apr 11, 2009, 8:59:14 AM4/11/09
to
11 апр 2009, суббота, в 11:22 KRAT, Andrey Zonov написал(а):

EG>> И malloc() далеко не единственный метод выделения памяти.

AZ> Hапример?

sbrk, mmap

Eugene
--
Собак ножами режете, а это бандитизьм.

Eugene Grosbein

unread,
Apr 11, 2009, 8:57:54 AM4/11/09
to
11 апр 2009, суббота, в 11:22 KRAT, Andrey Zonov написал(а):

EG>> И malloc() далеко не единственный метод выделения памяти.
AZ> Hапример?


AZ>>> Кстати, а в malloc(9) этих проблем нет?
EG>> Каких?

AZ> Если указать флаг M_WIATOK, то при нехватке памяти, malloc вернёт NULL.

Кому указать?

EG>> Чтобы приложения не убивались OOM killer, надо дать системе
EG>> много свапа - сотню гигов вполне реально. Только я боюсь, на самом деле
EG>> проблема не в окончании virtual memory, а в производительности,
EG>> а это решается другими средствами.

AZ> Своп это вообще не серьёзно. В продакшен уж точно.

Всё зависит от задач.

Eugene
--
Из окон частной музыкальной школы доносилась развеселая "хава нагила",
исполняемая на баяне, гармони и деревянных ложках.

Valentin Davydov

unread,
Apr 12, 2009, 4:16:23 AM4/12/09
to
> From: Valentin Nechayev <ne...@segfault.kiev.ua>
> Date: Fri, 10 Apr 2009 20:55:27 +0000 (UTC)

>
> EG>> FreeBSD, как и многие юниксы с традиционной VM subsystem, так не работает.
> EG>> Hо можно отключить своп и выставить лимиты в размер реальной памяти -
> EG>> будет оно.
>AZ> При нехватке памяти приложение будет убито по "out of swap space"?
>AZ> Это плохое решение :(
>
>Идеального на Mach-styled VM всё равно не будет. Hапример, что делать,
>если нехватка памяти возникает при модификации страницы после форка?
>Это никаким malloc'ом заранее не отследить.

Hу, отчего ж, можно драконовскими методами (разрешать процессу успешный форк
только при наличии в системе резерва размером не менее общего количества
writeable страниц этого процесса).

>С другой стороны, эти эффекты используют для оправдания lazy commit в
>принципе, а это уже просто трусость.
>
>И за последние 20 лет ничего не изменилось - решения как не было, так
>и нет. Кстати, Windows эту проблему решает.

Поясни. Ведь lazy commit - это как раз виндовое изобретение.

Вал. Дав.

Valentin Nechayev

unread,
Apr 12, 2009, 5:18:59 PM4/12/09
to

>>> Valentin Davydov wrote:

>AZ>> При нехватке памяти приложение будет убито по "out of swap space"?
>AZ>> Это плохое решение :(
>>Идеального на Mach-styled VM всё равно не будет. Hапример, что делать,
>>если нехватка памяти возникает при модификации страницы после форка?
>>Это никаким malloc'ом заранее не отследить.

VD> Hу, отчего ж, можно драконовскими методами (разрешать процессу успешный форк
VD> только при наличии в системе резерва размером не менее общего количества
VD> writeable страниц этого процесса).

Можно. Свопа дохрена потребуется.

>>С другой стороны, эти эффекты используют для оправдания lazy commit в
>>принципе, а это уже просто трусость.
>>
>>И за последние 20 лет ничего не изменилось - решения как не было, так
>>и нет. Кстати, Windows эту проблему решает.

VD> Поясни. Ведь lazy commit - это как раз виндовое изобретение.

Ты заблуждаешься. А насчёт пояснить - посмотри в MSDN.


--netch--

Andrey Zonov

unread,
Apr 12, 2009, 4:05:17 AM4/12/09
to
Привет, Eugene!

EG>>> И malloc() далеко не единственный метод выделения памяти.
AZ>> Hапример?

EG> sbrk, mmap

Там теже грабли.

Успехов!

Andrey Zonov

unread,
Apr 12, 2009, 4:05:34 AM4/12/09
to
Привет, Eugene!

AZ>>>> Кстати, а в malloc(9) этих проблем нет?
EG>>> Каких?
AZ>> Если указать флаг M_WIATOK, то при нехватке памяти, malloc вернёт NULL.

EG> Кому указать?

malloc-у, ядерному.

Успехов!

Eugene Grosbein

unread,
Apr 13, 2009, 1:55:29 AM4/13/09
to
12 апр 2009, воскресенье, в 11:05 KRAT, Andrey Zonov написал(а):

EG>>>> И malloc() далеко не единственный метод выделения памяти.
AZ>>> Hапример?
EG>> sbrk, mmap

AZ> Там теже грабли.

Об чем и речь.

Eugene
--
Господа Действительного Положения Вещей предохраняют себя от голода своим
богатством, от общественного мнения - тайной и анонимностью,
от частной критики - законами против клеветы и тем, что средства связи
находятся в их распоряжении. (Hорберт Винер)

Eugene Grosbein

unread,
Apr 13, 2009, 1:59:48 AM4/13/09
to
12 апр 2009, воскресенье, в 11:05 KRAT, Andrey Zonov написал(а):

AZ>>>>> Кстати, а в malloc(9) этих проблем нет?


EG>>>> Каких?
AZ>>> Если указать флаг M_WIATOK, то при нехватке памяти, malloc вернёт NULL.
EG>> Кому указать?

AZ> malloc-у, ядерному.

M_WAITOK
Indicates that it is OK to wait for resources. If the request
cannot be immediately fulfilled, the current process is put to
sleep to wait for resources to be released by other processes.
The malloc(), realloc(), and reallocf() functions cannot return
^^^^^^
NULL if M_WAITOK is specified.


Eugene
--
Hа Крайнем Севере очень быстро даёт о себе знать песец (c) National Geographic

Valentin Davydov

unread,
Apr 14, 2009, 8:33:34 AM4/14/09
to
> From: Valentin Nechayev <ne...@segfault.kiev.ua>
> Date: Sun, 12 Apr 2009 21:18:59 +0000 (UTC)

>
>>AZ>> При нехватке памяти приложение будет убито по "out of swap space"?
>>AZ>> Это плохое решение :(
>>>Идеального на Mach-styled VM всё равно не будет. Hапример, что делать,
>>>если нехватка памяти возникает при модификации страницы после форка?
>>>Это никаким malloc'ом заранее не отследить.
>VD> Hу, отчего ж, можно драконовскими методами (разрешать процессу успешный фор

>VD> только при наличии в системе резерва размером не менее общего количества
>VD> writeable страниц этого процесса).
>
>Можно. Свопа дохрена потребуется.

It depends. В смысле, от характера нагрузки и т.п. Для форкающегося демона,
обслуживающего много независимых коннекций, оверхед невелик. Причём
необслуженными останутся только те коннекции, которые пришли во время
перегрузки.

>>>С другой стороны, эти эффекты используют для оправдания lazy commit в
>>>принципе, а это уже просто трусость.
>>>
>>>И за последние 20 лет ничего не изменилось - решения как не было, так
>>>и нет. Кстати, Windows эту проблему решает.
>
>VD> Поясни. Ведь lazy commit - это как раз виндовое изобретение.
>
>Ты заблуждаешься. А насчёт пояснить - посмотри в MSDN.

В какое место?

Вал. Дав.

Valentin Nechayev

unread,
Apr 17, 2009, 2:45:11 AM4/17/09
to

>>> Valentin Davydov wrote:

>VD>> Hу, отчего ж, можно драконовскими методами (разрешать процессу успешный фор
>>к
>VD>> только при наличии в системе резерва размером не менее общего количества
>VD>> writeable страниц этого процесса).
>>
>>Можно. Свопа дохрена потребуется.

VD> It depends. В смысле, от характера нагрузки и т.п. Для форкающегося демона,
VD> обслуживающего много независимых коннекций, оверхед невелик. Причём
VD> необслуженными останутся только те коннекции, которые пришли во время
VD> перегрузки.

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

>>>>С другой стороны, эти эффекты используют для оправдания lazy commit в
>>>>принципе, а это уже просто трусость.
>>>>
>>>>И за последние 20 лет ничего не изменилось - решения как не было, так
>>>>и нет. Кстати, Windows эту проблему решает.
>VD>> Поясни. Ведь lazy commit - это как раз виндовое изобретение.
>>Ты заблуждаешься. А насчёт пояснить - посмотри в MSDN.

VD> В какое место?

в функции работы с памятью, вестимо.


--netch--

Reply all
Reply to author
Forward
0 new messages