Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
Коллеги, Помогите, пожалуйста, разобраться. Стоит PostgreSQL 8.0.8 на Linux localhost 2.4.21-32.0.1 #1 SMP Thu Jun 16 08:56:57 MSD 2005 i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel GNU/Linux фишка в том, что с некоторого времени при первом же запросе к базе пострес начинает съедать все ресурсы - пока его не перегрузишь. После чего появились такие проблемы - сказать очень трудно - на сервере много баз - несколько админов и понять кто и что уже абсолютно нереально... Подскажите, пожалуйста, из-за чего могли возникнуть такие проблемы? Конфиг: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Остальные параметры - по умолчанию. postmaster.conf: Код: plaintext Помогите пожалуйста! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2007, 18:04 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
Eleas Помогите пожалуйста! Nu, vo-pervyh, ia dumayu, vnimatelno prochitat' eto (otsuda: http://www.postgresql.org/docs/8.0/static/runtime-config.html): documentationshared_buffers (integer) Sets the number of shared memory buffers used by the database server. The default is typically 1000, but may be less if your kernel settings will not support it (as determined during initdb). Each buffer is 8192 bytes, unless a different value of BLCKSZ was chosen when building the server. This setting must be at least 16, as well as at least twice the value of max_connections; however, settings significantly higher than the minimum are usually needed for good performance. Values of a few thousand are recommended for production installations. This option can only be set at server start. Increasing this parameter may cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 16.5.1 for information on how to adjust those parameters, if necessary. i sootvetstvenno izmenit' shared_buffers. V dobavku, obnovitsia s 8.0.8 do 8.0.13 V tret'ih, sdelat' VACUUM ANALYZE, esli ego davno ne delali ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2007, 18:21 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
Сергей, С shared_buffers 1024 - тоже самое. :( А что нового в 8.0.13 по сравнению с 8.0.8? Дело в том, что сейчас мне для обновления в gentoo доступно только 8.0.11. Достаточно ли обновиться до 8.0.11? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2007, 18:51 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
EleasСергей, С shared_buffers 1024 - тоже самое. :( Hmm... nadeus' server vy perezapuskali ... Eleas А что нового в 8.0.13 по сравнению с 8.0.8? Дело в том, что сейчас мне для обновления в gentoo доступно только 8.0.11. Достаточно ли обновиться до 8.0.11? Nu navernoe eto ne prichina vashei problemy, prosto PG esli vypuskaet obnovlenia, to dlia korrectsii serioznyh bugov. Smotrite release notes: http://www.postgresql.org/docs/8.0/static/release-8-0-9.html http://www.postgresql.org/docs/8.0/static/release-8-0-10.html http://www.postgresql.org/docs/8.0/static/release-8-0-11.html http://www.postgresql.org/docs/8.0/static/release-8-0-12.html http://www.postgresql.org/docs/8.0/static/release.html#RELEASE-8-0-13 tam mnogo serioznyh bug'ov. A vozvrashaias' k vashei probleme -- vy sdelali VACUUM ANALYZE ? Net li chego kramolnogo v logah ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2007, 19:16 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
Попробуйте понять, какой именно запрос съедает весь CPU, с помощью pg_stat_activity и юниксовых top, ps, возможно netstat. Затем посмотрите план этого запроса через explain и explain analyze. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 10:07 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
Коллеги, Проблема, кажется начала проявляться с новой стороны... Через SQL все что касается VACUUM делал и по всем БД. Но(!) консольная утилита vaccuumdb c опцией -a до сих пор висит на одной из БД, и, что интересно, в этот же момент загрузка проца спала до приемлемой 4-5%. Вопрос может быть и глупый для кого-то покажется, но все-таки просветите: чем отличается работа vaccuumdb от "стандартных" операций по ваккуму через SQL? Лично я не могу приложить ума в чем может быть разница. To Сергей, Да - релиз ноутсы почитал и были даже несколько кандидатов на причину ошибки, но, все равно, при переустановке ошибка повторялась также... Подожду полной отработки vaccuumdb и если все-таки она поможет, то, скорее всего, это какой-то очень частный баг на физическом уровне разбора файлов данных. Всем спасибо!:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 10:57 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
LeXa NalBat, проблема, как раз, и заключалась в том, что загрузка возникала при любом обращении к базе. Выглядело так: перегружаешь БД - загрузка минимальная. Открываешь pgAdmin3 и коннектишься к любой базе. Иногда достаточно просто "походить" по структуре, но чаще загрузка возрастала при простом селекте типа Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 11:02 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
Может быть из-за большого кол-ва изменений структуры объектов распухли системные таблицы. Я бы попробовал кардинальный способ: pg_dumpall >pg.dmp postgresql stop rm -rf .../data/ postgresql start cat pg.dmp | psql ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 11:17 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
Eleas Вопрос может быть и глупый для кого-то покажется, но все-таки просветите: чем отличается работа vaccuumdb от "стандартных" операций по ваккуму через SQL? Лично я не могу приложить ума в чем может быть разница. Nichem. Kstati, ia by navernoe daje (raz ia ranshe etogo ne skazal) daje prekratil vacuumdb. Sdelal by maintenance_work_mem sushestvenno pobolshe ( http://www.postgresql.org/docs/8.0/static/runtime-config.html#GUC-MAINTENANCE-WORK-MEM ) (chtoby vse poshustree shlo...) i zapustil vacuumdb s kluchom -v, chtoby videt' kak vse prodvigaetsia... . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 12:45 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
У меня такое было, когда база была физически запорчена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 15:00 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
HordiУ меня такое было, когда база была физически запорчена.можно предположить к примеру (программный?) рейд5 + проблемы с данными именно постгреса. думается в таком случае загрузить проц расчетом удастся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 15:11 |
|
||
|
postgres съедает 100% проца...
|
|||
|---|---|---|---|
|
#18+
И у меня на Postgres 8.1.8 приключилась 100 % загрузка после возни с построителем отчетов. Process explorer показал что три процесса postgres отобрали по 33 процента ЦПУ, в итоге - тормоза. В логах сказано, что соединение было несколько раз разорвано неожиданно. Селекты, которые запускались из отчета были не тяжелые, результат возвращался быстро. И автоваккум у меня отключен. Припомнилось мне, что и ранее при работе с построителем отчета (бывает там синтаксически селект не так построишь) приключалось пожирание ЦПУ. Если это только от разрыва соединения, то вообщем пока терпимо. Уважаемые специалисты, кто что скажет на это ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 13:27 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=295&tid=2005387]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 399ms |

| 0 / 0 |
