|
|
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
есть виртуалка (вмварь), на core i5 ноуте. ей выделено 2 гб озу в ней psql 8.1.23 (server 9.0.4) делю дроб базы, база в пару гиг. дроп идет уже 10 часов. подключений к ней нету, 100%. так как виртуалка - это клон другого сервера. просто готовлю вм для тестов. как быть, куда копать? также тут есть база в 190гб, сейчас чищу таблицы, идет тоже очень медленно. там есть таблицы, где есть 7-9 млн записей статистики, я оставляю несколько тыс записей, но при этом размер базы на диске - меньше не становится, автовакум при этом срабатывал. я так понимаю надо еще vacum full делать - он поможет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2014, 20:56:44 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobin, вы таки посмотрите pg_stat_activity по2: вы бы скинули сколько вам надо в новую "буферную" табличку, транкейтнули старую, потом залили туда из вашей буферной ну и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 07:17:46 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
дык думать надоAlexandr Zlobin, вы таки посмотрите pg_stat_activity как раз через него и смотрел - к базе которая удаляется - только один запрос - drop database прошло 18 часов - так и не дропнуло - я ребутнул виртуалку, дальше нет сил ждать. честно говоря не понимаю что не так. дык думать надоAlexandr Zlobin, вы таки посмотрите pg_stat_activity по2: вы бы скинули сколько вам надо в новую "буферную" табличку, транкейтнули старую, потом залили туда из вашей буферной ну и т.п. пробовал, удаление или TRUNCATE - тоже идет очень долго. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 09:11:30 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobin, когда делается drop database, посмотрите в top есть ли там какая активность (CPU%, user, iowait)? по п.2 попробуйте pgcompactor , обойдется без vacuum full ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 09:56:35 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobin, и покажите postgresql.conf той машины где база в 190GB ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 09:58:19 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
в top скачет активность по процу cat с оригинала: Код: 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. 36. 37. 38. 39. с моего Код: 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. 36. 37. 38. 39. подключился ems sql managerом - там есть конфигурация сервера - и куча параметров. - где они хранятся и могли ли их накрутить? топ: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4207 postgres 25 0 345m 17m 15m R 98.2 0.9 4:25.49 postmaster select * from pg_stat_activity; Код: sql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 10:56:36 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobinкак раз через него и смотрел - к базе которая удаляется - только один запрос - drop database прошло 18 часов - так и не дропнуло - я ребутнул виртуалку, дальше нет сил ждать. честно говоря не понимаю что не так. смотрите активность, смотрите логи чем-то она у вас занимается как вариант - мог предположить, что модный триггер на ddl пользуете но вот это автор8.1.23 (server 9.0.4) при обоих вариантах рановато для такого. вы кстати расскажите, что именно у вас стоит. это легко выясняется с помощью SELECT version(); Alexandr Zlobinпробовал, удаление или TRUNCATE - тоже идет очень долго. посмотрите ещё триггера. если где-то стояла триггер-репликация, она может и транкейты обвешивать своими триггерами. НУ а прочие событие - по дефолту и не надо пробовать удалять, если времена транкейтов вас не устраивают. лучше пойдите, прикупите духовое ружьё, бельишко там поменяйте, короче с достоинством как-то по мужски ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 11:02:44 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
SELECT version(); version ------------------------------------------------------------------------------------------------------------------- PostgreSQL 9.0.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit (1 row) я , увы, не дба, я админ, все время работал либо с мускулом либо с мсскл, а с постгресом столкнулся недавно как еще можно проверить чем занята база? то что к ней нет внешних подключений - я уверен, так как виртуальная среда с закрытыми ип адресами. [quot дык думать надо]Alexandr Zlobinи не надо пробовать удалять, если времена транкейтов вас не устраивают. лучше пойдите, прикупите духовое ружьё, бельишко там поменяйте, короче с достоинством как-то по мужски этого стеба не понял. я вижу явную проблему либо настроек - так как перенесено с более мощной конфигурации на более слабую либо проблемы с самой базой времена транкейтов - долго - также как удаление, я пробовал очистить таблицу в 1,5 гб весом - тукже не дождался... прошло часов 8... или это не долго? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 11:10:38 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
[quot Alexandr Zlobin]SELECT version(); version ------------------------------------------------------------------------------------------------------------------- PostgreSQL 9.0.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit (1 row) я , увы, не дба, я админ, все время работал либо с мускулом либо с мсскл, а с постгресом столкнулся недавно как еще можно проверить чем занята база? то что к ней нет внешних подключений - я уверен, так как виртуальная среда с закрытыми ип адресами. дык думать надопропущено... этого стеба не понял. я вижу явную проблему либо настроек - так как перенесено с более мощной конфигурации на более слабую либо проблемы с самой базой времена транкейтов - долго - также как удаление, я пробовал очистить таблицу в 1,5 гб весом - тукже не дождался... прошло часов 8... или это не долго? Это все очень долго... у вас какие то проблемы с операционкой или железом или просто дикая перегрузка по диску... что drop database что truncate занимают секунды (минуты в самом плохом случае) для начала посмотрите на утилизацию IO на хост системе (я что то думаю что ноутбучный винт штука не быстрая весьма) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 12:01:32 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
я верю что долго. только что проверил на паре других таблиц truncate - отработало нормально + было заметно как освобождается место с дропом - таки непонятно, была еще одна тесовая база в 700 мб - удалилась мгновенно. сейчас делаю полное восстановление папки data (204 гб, на данный винт, проходит за часов 5 вроде, это с учетом того, что на нем же и лежит) потом поиграюсь еще есть какие-то варианты проверки всей базы на валидность (побились файлы например или еще что то? ) могут ли влиять параметы внутри сервера? то что показывает ems ? как их увидеть и поменять запросом? (в мускуле я так понимаю это те параметры: mysqladmin variables -uroot -p ) - и какие среди них надо менять, если сервер стал слабее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 12:08:33 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
мне непонятно, почему дроп происходит дольше, чем обычное коприование файлов в систему.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 12:12:44 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobin, коннект у вас висит вероятно к базе этой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 17:16:04 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
запустите БД в single mode и вообще на другом порту Чтобы наверняка у вас никто подключен не был и попробуйте drop ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 17:27:26 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
я без сети запускал - не дропается. видимо какие-то тригерры или еще какие то внутренние скрипты -как это выловить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 17:40:35 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Кстати, если делаешь дамп базы - все тригерры и вставки и тд (насколько знаю - тут в 200гб базе есть вставки на питоне и перле вроде, как мне сказали - что это и где искать - тоже не знаю.) сохраняются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2014, 17:42:12 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
вчера, по техническим причинам пришлось отложить восстановление. сейчас начал подскажите, как проверить есть ли в базе тригерры? есть ли какие то скрипты\таски во внутреннем кроне? как проверить есть ли какие то вставки на питоне\перле и тд, к базе? спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2014, 19:52:17 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobinвчера, по техническим причинам пришлось отложить восстановление. сейчас начал подскажите, как проверить есть ли в базе тригерры? есть ли какие то скрипты\таски во внутреннем кроне? как проверить есть ли какие то вставки на питоне\перле и тд, к базе? спасибо ничего из этого не может мешать drop database внутреннего крона у postgresql нет (штатного) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2014, 04:05:21 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobinесть виртуалка (вмварь) Alexandr Zlobinвиртуалка - это клон другого сервера. скажите, пожалуйста, а ваша виртуалка-клон не linked ли случаем? также интересует, примерно сколько у вас в дропаемой базе таблиц и индексов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2014, 09:30:00 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukничего из этого не может мешать drop database внутреннего крона у postgresql нет (штатного) понял. когда я делал shell скрипт, который запускался через watch каждые 10 сек, и выполнял обновление в mysql базе. потом мне дба сказал что будет запускать его в самом мускуле, я не уточнял как, было это давно и было не до этого. но насколько я понял - есть какой то внутренний механизм запуска подобных вещей в мускуле, и может и в постргнессе - не подскажете как он называется? buddy_ekbскажите, пожалуйста, а ваша виртуалка-клон не linked ли случаем? также интересует, примерно сколько у вас в дропаемой базе таблиц и индексов. не linked, так как это клон физической машины. индексов - не знаю как посмотреть, таблиц - 107 может есть какой то дебаг режим, что бы отловить почему долго дропается и грузит при этом проц? сам сервер клонировал с помощью rsync, базу - т.е. папку data мне дали загзипованую, насколько мне обяснили - брали ее с рабочего сервера, не останавливая его, методом rsync-а тоже, в ней лежит в т.ч. файл backup_label человек который это все делал, уже уволился и проконсультироваться с ним нет возможности я же запускал по одному из нагугленных мануалов: chmod -R postgres:postgres /postgresql/data/ pg_controldata /postgresql/data/ | grep "Latest checkpoint" (брал нижние цифры) pg_resetxlog -o18766860 -x 16674550 -f /postgresql/data/ может тут неправильно? может есть какой то чек базы, который можно запустить и пусть идет себе ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2014, 10:25:50 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
я удалять базы пробовал от суперпользователя postgres попробовал его сделать ownerом на удаляемую базу - не помогло ( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2014, 20:03:35 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
добавил лог log_directory = 'pg_log' log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' log_statement = 'all' буду думать далее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2014, 21:52:04 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
пофигу... ничего нужного не обнаружил, дроп опять висит в логе: 2014-04-18 18:54:26.226 BST:*::**::***::****: LOG: database system was not properly shut down; automatic recovery in progress 2014-04-18 18:54:26.365 BST:*::**::***::****: LOG: consistent recovery state reached at 1417/B00BC468 2014-04-18 18:54:26.365 BST:*::**::***::****: LOG: record with zero length at 1417/B00BC468 2014-04-18 18:54:26.365 BST:*::**::***::****: LOG: redo is not required 2014-04-18 18:54:26.473 BST:*::**::***::****: LOG: autovacuum launcher started 2014-04-18 18:54:26.474 BST:*::**::***::****: LOG: database system is ready to accept connections 2014-04-18 18:57:53.367 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: select GLOBAL autovacuum; 2014-04-18 18:57:53.368 BST:*:[local]:**:template1:***:postgres:****: ERROR: column "global" does not exist at character 9 2014-04-18 18:57:53.368 BST:*:[local]:**:template1:***:postgres:****: STATEMENT: select GLOBAL autovacuum; 2014-04-18 18:58:07.404 BST:*:[local]:**:template1:***:postgres:****: ERROR: syntax error at or near "autovacuum" at character 12 2014-04-18 18:58:07.404 BST:*:[local]:**:template1:***:postgres:****: STATEMENT: SET GLOBAL autovacuum = off ; 2014-04-18 18:58:19.692 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database WHERE substring(pg_catalog.quote_ident(datname),1,1)='j' LIMIT 1000 2014-04-18 18:58:21.699 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: SELECT pg_catalog.quote_ident(datname) FROM pg_catalog.pg_database WHERE substring(pg_catalog.quote_ident(datname),1,9)='db_1' LIMIT 1000 2014-04-18 18:58:23.157 BST:*:[local]:**:template1:***:postgres:****: LOG: statement: DROP DATABASE db_1; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2014, 22:03:53 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
попробовал установить postgres заново с rpm - не помогло. есть еще какие то идеи? помогите, плиз неделю уже мучаюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2014, 04:49:41 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobinпопробовал установить postgres заново с rpm - не помогло. есть еще какие то идеи? помогите, плиз неделю уже мучаюсь. вы этта, вы CREATE DATABASE на том же инстансе попробуйте. Посмотрите, как оно на DROP новой отреагирует. а так как в том анеке: -- сдохли они, ребе. -- жаль, а у меня ещё столько идей вы, надеюсь, SELECT * from pg_locks; тоже смотрели в момент "зависания" ? и да, погоняйте всё это из консоли --т.е. psql, а не из под непойми каких приблуд. может быть вы какой-то notice/warning пропускаете ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2014, 13:01:13 |
|
||
|
drop database (около 2 гб ) длится уже более 10 часов
|
|||
|---|---|---|---|
|
#18+
Alexandr Zlobinпопробовал установить postgres заново с rpm - не помогло. есть еще какие то идеи? помогите, плиз неделю уже мучаюсь. 1)поробуйте checkpoint; сделать перед drop database и посмотрите сколько времени он займет и не сработает ли drop database после этого 2)попробуйте сделать пустую базу и drop ее 3)во время drop откройте еще одну консоль к базе и проверьте что нет НИКАКИХ соединений с той базой которую вы пробуете drop ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2014, 13:17:56 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=129&tid=1998720]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
72ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 390ms |

| 0 / 0 |
