Доброго времени суток.
Debian8, в ней VirtualBox, в ней Debian8, в ней Postgres9.4, i7 4770/HDDСистема ни чем не занята, запускаю один сложный select - нагрузка того ядра на который он попал сразу 100%, и если потом на это ядро попадает еще кто нибудь то он повисает пока select не закончится, если же попадает на другое ядро то все норм.
Не могу понять, ОС ведь должна делить ядро между процессами? почему так происходит? куда копать?
> Доброго времени суток.
> Debian8, в ней VirtualBox, в ней Debian8, в ней Postgres9.4, i7 4770/HDD
> Система ни чем не занята, запускаю один сложный select - нагрузка того
> ядра на который он попал сразу 100%, и если потом на
> это ядро попадает еще кто нибудь то он повисает пока select
> не закончится, если же попадает на другое ядро то все норм.
> Не могу понять, ОС ведь должна делить ядро между процессами? почему так
> происходит? куда копать?может быть из за вот этого: https://lwn.net/Articles/518329/
и может быть попробовать провести тесты не в виртуалк тоже.возможно(где назначение ядер на определенные задачи наоборот может сказаться на производительности) можно будет поиграть утилитами taskset или schedtool чтобы привязать использование ядер.
Почитайте:
http://postgresql.nabble.com/Performance-degrade-running-on-...
http://www.postgresql.org/message-id/4B78497A.7070606@c...
http://www.commandprompt.com/blogs/alexey_klyukin/2012/06/bi.../
в google: Scaling PostgreSQL on SMP Architectures
Спасибо. Выясняется что все несколько сложнее, можно загрузить все 4 ядра под завязку и при этом новые соединения будут обслуживаться, а иногда достаточно одного чтобы новые висели, такое впечатление как лок в базе, но там только select'ы и лок новых клиентов на стадии коннекта. Есть тут еще PgBouncer, но по предварительным тестам от него не зависит..
> Debian8, в ней VirtualBox, в ней Debian8, в ней Postgres9.4"Я молчать не буду! Тиграм в VB процессора не докладывают!!"