|
|
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Железо (да-да, знаю, не серверное): cpu intel core i5 2500K ram 32GB 1333 DDR3 hdd seagate st1000dm003 postgresql 9.1.5, собранный на gentoo с настройками из коробки. FS: ext4 connect: localhost База: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. Втыкаю 500 сообщений в секунду в базу messages запросом вида: Код: sql 1. Обращаюсь 500 раз в секунду в базу users запросом вида: Код: sql 1. Периодически первый INSERT уходит в шуршание HDD секунд на 10. Периодически: точно не скажу - может быть раз в 30 минут. Вопрос: как исключить подобные уходы в себя? Неужели только заменой дисковой подсистемы на "взрослую"? 500 подобных INSERT-ов в секунду - разве много? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2014, 19:27:02 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Подозреваю что затык происходит во время операции checkpoint. Покажите опции postgresql.conf : checkpoint_timeout, checkpoint_completion_target, checkpoint_segments. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2014, 20:26:42 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
daevyПодозреваю что затык происходит во время операции checkpoint. Покажите опции postgresql.conf : checkpoint_timeout, checkpoint_completion_target, checkpoint_segments. Закомментировано (видимо дефолтное). Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2014, 20:43:56 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
ia6514, Есть несколько возможностей, который Вам нужно проверить: 0. Какой $#$#$#% пишет таблицы без первичных ключей? 1. Уникальный индекс создается дважды: в момент создания константы и в явном виде в виде создания индекса. Индекс по bytea - посмотрите, какой у него размер. И это все создается дважды. 2. Какие настройки у сервера (postgresql.conf)? По умолчанию настройки позволяют заводиться серверу даже на зажигалке. То есть для работы их нужно изменить. 3. Отдельно проверьте работу функции md5. Думаю скорость ее работы Вас озадачит. (И нам сообщите) Шуршание диском - это вполне обыкновенно. Идет заполнение кешей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2014, 21:40:45 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
/\/\/\/\/\/\/\ia6514, Есть несколько возможностей, который Вам нужно проверить: 0. Какой $#$#$#% пишет таблицы без первичных ключей? 1. Уникальный индекс создается дважды: в момент создания константы и в явном виде в виде создания индекса. Индекс по bytea - посмотрите, какой у него размер. И это все создается дважды. 2. Какие настройки у сервера (postgresql.conf)? По умолчанию настройки позволяют заводиться серверу даже на зажигалке. То есть для работы их нужно изменить. 3. Отдельно проверьте работу функции md5. Думаю скорость ее работы Вас озадачит. (И нам сообщите) Шуршание диском - это вполне обыкновенно. Идет заполнение кешей. UNIQUE NOT NULL - это то же самое, что PRIMARY KEY. Тут написано: http://www.postgresql.org/docs/8.1/static/ddl-constraints.html (искать по "primary key"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.02.2014, 23:21:30 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
/\/\/\/\/\/\/\ia6514, Есть несколько возможностей, который Вам нужно проверить: 0. Какой $#$#$#% пишет таблицы без первичных ключей? 1. Уникальный индекс создается дважды: в момент создания константы и в явном виде в виде создания индекса. Индекс по bytea - посмотрите, какой у него размер. И это все создается дважды. 2. Какие настройки у сервера (postgresql.conf)? По умолчанию настройки позволяют заводиться серверу даже на зажигалке. То есть для работы их нужно изменить. 3. Отдельно проверьте работу функции md5. Думаю скорость ее работы Вас озадачит. (И нам сообщите) Шуршание диском - это вполне обыкновенно. Идет заполнение кешей. 3) Скорость выполнения запроса пока не волнует, интересует возникновение периодических затыков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 04:29:52 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
ia6514Закомментировано (видимо дефолтное). Код: plaintext 1. 2. 3. 4. попробуйте выставить следующим образом и посмотрите как пойдет дальше checkpoint_segments = 32 checkpoint_timeout = 20min checkpoint_completion_target = 0.9 при установке checkpoint_segments смотрите чтобы у вас было свободное место под сегменты, из расчета что один сегмент занимает 16MB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 08:27:54 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
ia6514UNIQUE NOT NULL - это то же самое, что PRIMARY KEY. Тут написано: http://www.postgresql.org/docs/8.1/static/ddl-constraints.html (искать по "primary key"). Если прочитаете указанное Вами до конца, то увидите: авторA table can have at most one primary key (while it can have many unique and not-null constraints) Таким образом, это не то же самое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 10:55:01 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
ia6514 Спасибо. зачем 2 индекса у месседжей? поиск будет по какому полю? или вообще не будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 14:10:09 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
/\/\/\/\/\/\ia6514UNIQUE NOT NULL - это то же самое, что PRIMARY KEY. Тут написано: http://www.postgresql.org/docs/8.1/static/ddl-constraints.html (искать по "primary key"). Если прочитаете указанное Вами до конца, то увидите: авторA table can have at most one primary key (while it can have many unique and not-null constraints) Таким образом, это не то же самое. Не увидел, как вторая фраза относится к делу: таблица может иметь максимум один примари кей. Ну и что? У меня тоже один примари кей, (написанный в форме UNIQUE NOT NULL) и что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 15:05:01 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Ivan Durakia6514Спасибо. зачем 2 индекса у месседжей? поиск будет по какому полю? или вообще не будет? Поиск по 2 полям: id (вытащить сообщение по id), hash (проверить если такое сообщение уже при добавлении нового; это база индексации сообщений, в которой не нужны одинаковые месаги). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 15:06:26 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
phasenoisepskcodedcompressionIvan Durakпропущено... зачем 2 индекса у месседжей? поиск будет по какому полю? или вообще не будет? Поиск по 2 полям: id (вытащить сообщение по id), hash (проверить если такое сообщение уже при добавлении нового; это база индексации сообщений, в которой не нужны одинаковые месаги). как часто случается что при добавлении новая мессага оказывается с уже таким же хэшем?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 15:29:18 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Ivan Durakphasenoisepskcodedcompressionпропущено... Поиск по 2 полям: id (вытащить сообщение по id), hash (проверить если такое сообщение уже при добавлении нового; это база индексации сообщений, в которой не нужны одинаковые месаги). как часто случается что при добавлении новая мессага оказывается с уже таким же хэшем?? ну да, 500 взволнованных пользователей по 100500 раз пытаются прослать одинакое сообщение "кг/ам" , а это творение "кг/ам" ставит их в очередь по unique индексу на вставку. осмысленные тексты тем и отличаются от неосмысленных, что из множество существенно реже (менее плотно). при той же [потенциально] мощности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 15:55:40 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Ivan Durakphasenoisepskcodedcompressionпропущено... Поиск по 2 полям: id (вытащить сообщение по id), hash (проверить если такое сообщение уже при добавлении нового; это база индексации сообщений, в которой не нужны одинаковые месаги). как часто случается что при добавлении новая мессага оказывается с уже таким же хэшем?? Ну бывает иногда, в основном когда юзер запостил одну ссылку на картинку. Ссылки вырезаем, получается пустая месага. Таких много ) Или много месаг типа "плюсадин", "поржал". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 16:02:54 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
этот хеш и индекс на нем жрет дохрена ресурсов. Вставка сильно ускорится если его выкинуть совсем. пустые мессаги и так можно выкинуть. А всякие "плюсадин" быстрее второй раз вставить , чем ради них целый хэш с индексом городить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 18:03:44 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Ivan Durakэтот хеш и индекс на нем жрет дохрена ресурсов. Вставка сильно ускорится если его выкинуть совсем. пустые мессаги и так можно выкинуть. А всякие "плюсадин" быстрее второй раз вставить , чем ради них целый хэш с индексом городить. Ну это вроде-бы понятно. Но вопрос не в этом ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 18:20:36 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
phasenoisepskcodedcompressionIvan Durakпропущено... зачем 2 индекса у месседжей? поиск будет по какому полю? или вообще не будет? Поиск по 2 полям: id (вытащить сообщение по id), hash (проверить если такое сообщение уже при добавлении нового; это база индексации сообщений, в которой не нужны одинаковые месаги). Ересь. Ибо: ia6514Обращаюсь 500 раз в секунду в базу users запросом вида: SELECT id FROM users WHERE name = %s; Где это тут поиск по id??? Так что - в газенва на костер. И после сожжения - создать индекс по name, посмотреть на его размер, и выставить shared_buffers адекватно этому размеру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 19:29:57 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Уж чего чего, а 32 гигов ОЗУ на один индекс хватить должно :) Меня, кстати, терзают смутные сомненья, что ia6514 == phasenoisepskcodedcompression ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 19:32:20 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Hawkmoonphasenoisepskcodedcompressionпропущено... Поиск по 2 полям: id (вытащить сообщение по id), hash (проверить если такое сообщение уже при добавлении нового; это база индексации сообщений, в которой не нужны одинаковые месаги). Ересь. Ибо: ia6514Обращаюсь 500 раз в секунду в базу users запросом вида: SELECT id FROM users WHERE name = %s; Где это тут поиск по id??? Так что - в газенва на костер. И после сожжения - создать индекс по name, посмотреть на его размер, и выставить shared_buffers адекватно этому размеру. Не, ну есть конечно недоработки с индексами. Но вопрос не про скорость инсерта, а про затыки с HDD. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 19:37:20 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
HawkmoonУж чего чего, а 32 гигов ОЗУ на один индекс хватить должно :) Меня, кстати, терзают смутные сомненья, что ia6514 == phasenoisepskcodedcompression Ну в разных браузерах разные ники, эхо войны с модерами в соседнем разделе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 19:38:29 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
phasenoisepskcodedcompressionHawkmoonпропущено... Ересь. Ибо: пропущено... Где это тут поиск по id??? Так что - в газенва на костер. И после сожжения - создать индекс по name, посмотреть на его размер, и выставить shared_buffers адекватно этому размеру. Не, ну есть конечно недоработки с индексами. Но вопрос не про скорость инсерта, а про затыки с HDD. Скажем так, имеющиеся индексы вообще неадекватны ни одному (единственному, к слову) запросу поиска. Если, при этом, нет понимания на затраты на перестроение индекса при вставке - то вперед, ботать матчасть. Любой индекс - уменьшение скорости insert'а. Хотя что-то мне подсказывает, что нам просто не все говорят... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 19:46:28 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
phasenoisepskcodedcompression, Опять-таки, и мне лично это очевидно, даже без взгляда на shared_buffers (кстати, где он?) то, что идет пересвопинг индекса с HDD. Потому что доперестраивались. Потому что достроили ненужных индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 19:49:03 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
И да, в плане издевательства, если у тебя, дорогой, shared_buffers тоже закомментирован, то есть по дефолту, то советую вызвать show shared_buffers, порыдать, почитать, почему так, подумать, еще раз подумать и отдать мне разницу между тем, что увидел в консоли, и наличествующей бесхозной памятью. гыг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 19:53:06 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Hawkmoonphasenoisepskcodedcompressionпропущено... Не, ну есть конечно недоработки с индексами. Но вопрос не про скорость инсерта, а про затыки с HDD. Скажем так, имеющиеся индексы вообще неадекватны ни одному (единственному, к слову) запросу поиска. Если, при этом, нет понимания на затраты на перестроение индекса при вставке - то вперед, ботать матчасть. Любой индекс - уменьшение скорости insert'а. Хотя что-то мне подсказывает, что нам просто не все говорят... Я не очень понимаю, почему мы говорим о скорости инсертов, когда вопрос стоит о юзании HDD. Интересует природа этого явления, а не скорость отработки каких-либо указанных запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 20:21:54 |
|
||
|
Чему тормозить в таком алгоритме работы?
|
|||
|---|---|---|---|
|
#18+
Hawkmoonphasenoisepskcodedcompression, Опять-таки, и мне лично это очевидно, даже без взгляда на shared_buffers (кстати, где он?) то, что идет пересвопинг индекса с HDD. Потому что доперестраивались. Потому что достроили ненужных индексов. А что такое пересвопинг индекса с HDD? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2014, 20:22:19 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38555684&tid=1998854]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
164ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 212ms |
| total: | 448ms |

| 0 / 0 |
