Re: Geo проблема

[Igor Sysoev]

> >> ipblocklist.conf:
> >>
> >> 10.10.10.111    ab|bc;
> >> 10.10.10.189    ab|bc;
> >> 10.10.252.101   bc|defg;
> >> 10.100.10.100   ab|bc|defg;
> >> ...
> >>
> >> ~670,000 линий, всего 13M на диске.
> > На один бит в дереве radix расходуется 32 байта (для 64-битной архитектры).
> > На 32-битный адрес - 1024 байта, то есть, килобайт. Первые биты общие
> > для многих адресов. Сколько адреса займут памяти, грубо можно оценить так:
> > например, если у нас есть 670,000 адресов, отличающихся только последними
> > 16-ти битами (что, скорее всего, достаточно близко к приведённому случаю),
> > то они займут около:
> >
> > 4*8*16*670000 = 327M
> >
> > Для последних 8-ми бит:
> >
> > 4*8*8*670000 = 163M
> >
> > Вообще, geo лучше использует память для CIDR'ов, например, 10.10.10.0/24;
> > В этом случае последние 8 бит не хранятся, сохраняя 8К.
> >
> 
> Система 64 битовая. Список представляется мне разорванный (не CIDRовый), 
> но вроде все биты меняются.
> Надеялся что более компактно держится в памяти.

Можно попробовать map вместо geo, но будет долго грузиться.

> Ну а почему удваивается память при HUP?

Потому что nginx сначала обрабатывает новый конфиг и только после успешной
обработки освобождает старый. По идее malloc()/free() должны отдать память
ядру, но не хочет. Для того, чтобы убедиться, что со стороны nginx'а утечек
нет, можно послать -HUP несколько раз - память должна остататься всегда
в удвоенном объёме или меньше, но не увеличивается кратно числу HUPов.


-- 
Игорь Сысоев
http://sysoev.ru