Странная оптимизация
Apr. 25th, 2014 12:29 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclasshttps://github.com/twain47/Nominatim/blob/master/utils/setup.php#L395
$iInstances - количество работающих процессов, вычисляется как "количество процессоров-1".
Получается, что на постгрес отправляется параллельно несколько запросов, причем каждый запрос обрабатывает свое подмножество записей (условие osm_id % $iInstances = $i)
По идее, если запрос упирается в CPU (судя по нагрузке - таки да), это осмысленная оптимизация, если же в i/o, то выглядит это как-то странновато.
PS: впрочем там на вставку в placex обновляется gist индекс по положению + триггер placex_insert на пять страниц. Поэтому оно, похоже, адски CPU-bound.
Алсо, в 14.04 убунте уже 9.3 Postgresql и ему не нужно подкручивать kernel.shmmax, потому что https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.3#Switch_to_Posix_shared_memory_and_mmap.28.29
$iInstances - количество работающих процессов, вычисляется как "количество процессоров-1".
Получается, что на постгрес отправляется параллельно несколько запросов, причем каждый запрос обрабатывает свое подмножество записей (условие osm_id % $iInstances = $i)
По идее, если запрос упирается в CPU (судя по нагрузке - таки да), это осмысленная оптимизация, если же в i/o, то выглядит это как-то странновато.
PS: впрочем там на вставку в placex обновляется gist индекс по положению + триггер placex_insert на пять страниц. Поэтому оно, похоже, адски CPU-bound.
Алсо, в 14.04 убунте уже 9.3 Postgresql и ему не нужно подкручивать kernel.shmmax, потому что https://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.3#Switch_to_Posix_shared_memory_and_mmap.28.29
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-04-25 09:41 am (UTC)no subject
Date: 2014-04-25 09:43 am (UTC)no subject
Date: 2014-04-25 09:45 am (UTC)no subject
Date: 2014-04-25 10:08 am (UTC)no subject
Date: 2014-04-25 11:59 am (UTC)