Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Использование двух ядер...
|
|||
|---|---|---|---|
|
#18+
Приветствую всех! Проблема такая. Есть приложение, которое создает одно подключение с сервером PostgreSql 8.1.5, установленном на сервере с двухядерным процессором AMD X2 64 Dual Core processor 4200+ под управлением Suse Linux ядро 2.6.18.2-34-default. Приложение запускается на другой машине. Сервер используется только для PostgreSQL. В приложении используется многопоточная архитектура, где каждый из потоков использует одно соединение с SQL сервером. В результате с помощью top получаю, что используется только одно ядро под завязку!!! В итоге получается, что PostgreeSql в рамках одного соединения не может распределять нагрузку между ядрами или процессорами. Так ли это? С уважением Vector. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 08:09 |
|
||
|
Использование двух ядер...
|
|||
|---|---|---|---|
|
#18+
Vector В итоге получается, что PostgreeSql в рамках одного соединения не может распределять нагрузку между ядрами или процессорами. Так ли это? Да, это так. Одна сессия - один процесс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 10:03 |
|
||
|
Использование двух ядер...
|
|||
|---|---|---|---|
|
#18+
Vector В приложении используется многопоточная архитектура, где каждый из потоков использует одно соединение с SQL сервером. "каждый из потоков свое соединение", или "все потоки одно соединение"? Vector В итоге получается, что PostgreeSql в рамках одного соединения не может распределять нагрузку между ядрами или процессорами. Одно соединение - один процесс postgres, этот процесс не может использовать более одного ядра/процессора. Если в вашем многопоточном приложении есть хотя бы два потока, каждый из которых открывает свое соединение, то будет два процесса postgres и загрузка двух процессоров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 10:05 |
|
||
|
Использование двух ядер...
|
|||
|---|---|---|---|
|
#18+
Попробовал следующее: Запустил два приложения и подключился к одной базе. - В итоге два процесса и использование двух ядер! Все ОК.. Добавил дополнительное Connection в рамках одного приложения и запустил одно приложение, которое использует два соединения в разных потоках - в итоге два процесса postmaster, но делят они один процессор!!! Что-то я не понял, почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 10:19 |
|
||
|
Использование двух ядер...
|
|||
|---|---|---|---|
|
#18+
VectorПопробовал следующее: Запустил два приложения и подключился к одной базе. - В итоге два процесса и использование двух ядер! Все ОК.. Добавил дополнительное Connection в рамках одного приложения и запустил одно приложение, которое использует два соединения в разных потоках - в итоге два процесса postmaster, но делят они один процессор!!! Что-то я не понял, почему? На клиенте точно граблей нет? Т.е. таки реально используются 2 connection параллельно? Например в делфах при использовании synhronize() реально не будет параллельной работы. Думаю что PG глубоко плевать на то откуда берутся tcp/ip соединения на порту который он слушает. Берутся и хорошо :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 10:35 |
|
||
|
Использование двух ядер...
|
|||
|---|---|---|---|
|
#18+
Разобрался. Да, именно на клиенте были грабли. Дело в том, что все потоки обращались к одной synchronized функции, которая и возвращала набор данных. Теперь каждый поток имеет свою собственную функцию получения набора данных. Всем большое спасибо!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2007, 10:48 |
|
||
|
|

start [/forum/topic.php?fid=53&tid=2004827]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 407ms |

| 0 / 0 |
