drop database (около 2 гб ) длится уже более 10 часов / PostgreSQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / drop database (около 2 гб ) длится уже более 10 часов

48 сообщений из 48, показаны все 2 страниц

все

drop database (около 2 гб ) длится уже более 10 часов

#38615866

Alexandr Zlobin

Гость

есть виртуалка (вмварь), на core i5 ноуте.
ей выделено 2 гб озу
в ней psql 8.1.23 (server 9.0.4)
делю дроб базы, база в пару гиг.
дроп идет уже 10 часов.
подключений к ней нету, 100%. так как виртуалка - это клон другого сервера. просто готовлю вм для тестов.
как быть, куда копать?
также тут есть база в 190гб, сейчас чищу таблицы, идет тоже очень медленно. там есть таблицы, где есть 7-9 млн записей статистики, я оставляю несколько тыс записей, но при этом размер базы на диске - меньше не становится, автовакум при этом срабатывал.
я так понимаю надо еще vacum full делать - он поможет?

...

Рейтинг:

0 / 0

15.04.2014, 20:56:44

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616008

дык думать надо

Гость

Alexandr Zlobin,

вы таки посмотрите pg_stat_activity

по2: вы бы скинули сколько вам надо в новую "буферную" табличку, транкейтнули старую, потом залили туда из вашей буферной
ну и т.п.

...

Рейтинг:

0 / 0

16.04.2014, 07:17:46

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616060

Alexandr Zlobin

Гость

дык думать надоAlexandr Zlobin,
вы таки посмотрите pg_stat_activity

как раз через него и смотрел - к базе которая удаляется - только один запрос - drop database
прошло 18 часов - так и не дропнуло - я ребутнул виртуалку, дальше нет сил ждать.
честно говоря не понимаю что не так.
дык думать надоAlexandr Zlobin,
вы таки посмотрите pg_stat_activity
по2: вы бы скинули сколько вам надо в новую "буферную" табличку, транкейтнули старую, потом залили туда из вашей буферной
ну и т.п.
пробовал, удаление или TRUNCATE - тоже идет очень долго.

...

Рейтинг:

0 / 0

16.04.2014, 09:11:30

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616118

daevy

Гость

Alexandr Zlobin,

когда делается drop database, посмотрите в top есть ли там какая активность (CPU%, user, iowait)?

по п.2 попробуйте pgcompactor , обойдется без vacuum full

...

Рейтинг:

0 / 0

16.04.2014, 09:56:35

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616120

daevy

Гость

Alexandr Zlobin,

и покажите postgresql.conf той машины где база в 190GB

...

Рейтинг:

0 / 0

16.04.2014, 09:58:19

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616187

Alexandr Zlobin

Гость

в 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.

cat orig | grep -v '^#' | grep -v '^;' |sed '/^$/d' | more
                                        # (change requires restart)
                                        # (change requires restart)
                                        # (change requires restart)
max_connections = 1600                  # (change requires restart)
shared_buffers = 10000MB                # min 128kB
temp_buffers = 1024MB
work_mem = 512MB
maintenance_work_mem = 256MB
max_stack_depth = 2MB                   # min 100kB
wal_level = hot_standby                 # minimal, archive, or hot_standby
checkpoint_segments = 100
checkpoint_timeout = 10min
                                # (change requires restart)
archive_command = 'cp %p /opt/postgresql_9/xlog_archive/%f'     # command to use to archive a logfile segment
                                # number of seconds; 0 disables
cpu_tuple_cost = 0.001
cpu_index_tuple_cost = 0.0005
effective_cache_size = 10000MB
log_destination = 'stderr'
logging_collector = on                  # Enable capturing of stderr and csvlog
log_directory = '../log'                # directory where log files are written,
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
log_rotation_size = 100MB               # Automatic rotation of logfiles will
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
                                        #   debug5
                                        #   info
log_connections = off
log_line_prefix = '%m:*:%r:**:%d:***:%u:****: ' # special values:
log_statement = 'none'                  # none, ddl, mod, all
autovacuum_max_workers = 100            # max number of autovacuum subprocesses
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'                     # locale for system error message
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting
default_text_search_config = 'pg_catalog.english'
escape_string_warning = off

с моего

Код: 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.

max_connections = 100
shared_buffers = 256MB
effective_cache_size = 768MB
work_mem = 1310kB
maintenance_work_mem = 64MB
checkpoint_segments = 64
checkpoint_completion_target = 0.9
wal_buffers = 7864kB
default_statistics_target = 100

temp_buffers = 128MB
max_stack_depth = 2MB                   # min 100kB
wal_level = hot_standby                 # minimal, archive, or hot_standby
checkpoint_timeout = 10min
                                # (change requires restart)
archive_command = 'cp %p /opt/postgresql_9/xlog_archive/%f'     # command to use to archive a logfile segment
                                # number of seconds; 0 disables
cpu_tuple_cost = 0.001
cpu_index_tuple_cost = 0.0005
log_destination = 'stderr'
logging_collector = on                  # Enable capturing of stderr and csvlog
log_directory = '../log'                # directory where log files are written,
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
log_rotation_size = 100MB               # Automatic rotation of logfiles will
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
                                        #   debug5
                                        #   info
log_connections = off
log_line_prefix = '%m:*:%r:**:%d:***:%u:****: ' # special values:
log_statement = 'none'                  # none, ddl, mod, all
###autovacuum_max_workers = 100            # max number of autovacuum subprocesses
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'                     # locale for system error message
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting
default_text_search_config = 'pg_catalog.english'
escape_string_warning = off

подключился 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.

 16389 | voipdb    |    4024 |       10 | postgres | EMS | 91.201.21.1 |       27717 | 2014-04-16 07:06:49.657684+01 | | 2014-04-16 07:21:14.634232+01 | f       | <IDLE>
 16389 | voipdb    |    4207 |       10 | postgres | | |          -1 | 2014-04-16 07:20:06.215493+01 | 2014-04-16 07:47:22.55362+01  | 2014-04-16 07:47:22.55362+01  | f       | DROP DATABASE jiradb_v4 ;
     1 | template1 |    4123 |       10 | postgres | EMS | 91.201.21.1 |       27733 | 2014-04-16 07:13:32.840298+01 | | 2014-04-16 07:33:46.498962+01 | f       | <IDLE>
     1 | template1 |    5035 |       10 | postgres |  ||          -1 | 2014-04-16 07:52:55.513781+01 | 2014-04-16 07:52:58.494665+01 | 2014-04-16 07:52:58.494665+01 | f       | select * from pg_stat_activity;
     1 | template1 |    4284 |       10 | postgres | EMS | 91.201.21.1 |       28007 | 2014-04-16 07:33:49.051944+01 | | 2014-04-16 07:35:47.371176+01 | f       | <IDLE>
(5 rows)

...

Рейтинг:

0 / 0

16.04.2014, 10:56:36

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616197

дык думать надо

Гость

Alexandr Zlobinкак раз через него и смотрел - к базе которая удаляется - только один запрос - drop database
прошло 18 часов - так и не дропнуло - я ребутнул виртуалку, дальше нет сил ждать.
честно говоря не понимаю что не так.
смотрите активность,
смотрите логи
чем-то она у вас занимается

как вариант - мог предположить, что модный триггер на ddl пользуете
но вот это автор8.1.23 (server 9.0.4) при обоих вариантах рановато для такого.
вы кстати расскажите, что именно у вас стоит. это легко выясняется с помощью SELECT version();
Alexandr Zlobinпробовал, удаление или TRUNCATE - тоже идет очень долго.
посмотрите ещё триггера. если где-то стояла триггер-репликация, она может и транкейты обвешивать своими триггерами. НУ а прочие событие - по дефолту

и не надо пробовать удалять, если времена транкейтов вас не устраивают.
лучше пойдите, прикупите духовое ружьё, бельишко там поменяйте,
короче с достоинством как-то
по мужски

...

Рейтинг:

0 / 0

16.04.2014, 11:02:44

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616204

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)

я , увы, не дба, я админ, все время работал либо с мускулом либо с мсскл, а с постгресом столкнулся недавно

как еще можно проверить чем занята база? то что к ней нет внешних подключений - я уверен, так как виртуальная среда с закрытыми ип адресами.

[quot дык думать надо]Alexandr Zlobinи не надо пробовать удалять, если времена транкейтов вас не устраивают.
лучше пойдите, прикупите духовое ружьё, бельишко там поменяйте,
короче с достоинством как-то
по мужски
этого стеба не понял. я вижу явную проблему либо настроек - так как перенесено с более мощной конфигурации на более слабую
либо проблемы с самой базой

времена транкейтов - долго - также как удаление, я пробовал очистить таблицу в 1,5 гб весом - тукже не дождался... прошло часов 8...
или это не долго?

...

Рейтинг:

0 / 0

16.04.2014, 11:10:38

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616280

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

[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 на хост системе (я что то думаю что ноутбучный винт штука не быстрая весьма)

...

Рейтинг:

0 / 0

16.04.2014, 12:01:32

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616289

Alexandr Zlobin

Гость

я верю что долго.
только что проверил на паре других таблиц truncate - отработало нормально + было заметно как освобождается место
с дропом - таки непонятно, была еще одна тесовая база в 700 мб - удалилась мгновенно.

сейчас делаю полное восстановление папки data (204 гб, на данный винт, проходит за часов 5 вроде, это с учетом того, что на нем же и лежит)
потом поиграюсь еще

есть какие-то варианты проверки всей базы на валидность (побились файлы например или еще что то? )
могут ли влиять параметы внутри сервера? то что показывает ems ? как их увидеть и поменять запросом? (в мускуле я так понимаю это те параметры: mysqladmin variables -uroot -p ) - и какие среди них надо менять, если сервер стал слабее?

...

Рейтинг:

0 / 0

16.04.2014, 12:08:33

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616299

Alexandr Zlobin

Гость

мне непонятно, почему дроп происходит дольше, чем обычное коприование файлов в систему..

...

Рейтинг:

0 / 0

16.04.2014, 12:12:44

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616757

Misha Tyurin

Участник

Откуда: Тюмень

Сообщения: 2 279

Рейтинг: 0 / 0

Alexandr Zlobin,

коннект у вас висит вероятно к базе этой

...

Рейтинг:

0 / 0

16.04.2014, 17:16:04

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616777

landy

Участник

Сообщения: 1 531

Рейтинг: 0 / 0

запустите БД в single mode и вообще на другом порту
Чтобы наверняка у вас никто подключен не был
и попробуйте drop

...

Рейтинг:

0 / 0

16.04.2014, 17:27:26

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616795

Alexandr Zlobin

Гость

я без сети запускал - не дропается.
видимо какие-то тригерры или еще какие то внутренние скрипты -как это выловить?

...

Рейтинг:

0 / 0

16.04.2014, 17:40:35

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38616799

Alexandr Zlobin

Гость

Кстати, если делаешь дамп базы - все тригерры и вставки и тд (насколько знаю - тут в 200гб базе есть вставки на питоне и перле вроде, как мне сказали - что это и где искать - тоже не знаю.) сохраняются?

...

Рейтинг:

0 / 0

16.04.2014, 17:42:12

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38618020

Alexandr Zlobin

Гость

вчера, по техническим причинам пришлось отложить восстановление.
сейчас начал
подскажите, как проверить есть ли в базе тригерры?
есть ли какие то скрипты\таски во внутреннем кроне?
как проверить есть ли какие то вставки на питоне\перле и тд, к базе?
спасибо

...

Рейтинг:

0 / 0

17.04.2014, 19:52:17

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38618212

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

Alexandr Zlobinвчера, по техническим причинам пришлось отложить восстановление.
сейчас начал
подскажите, как проверить есть ли в базе тригерры?
есть ли какие то скрипты\таски во внутреннем кроне?
как проверить есть ли какие то вставки на питоне\перле и тд, к базе?
спасибо

ничего из этого не может мешать drop database
внутреннего крона у postgresql нет (штатного)

...

Рейтинг:

0 / 0

18.04.2014, 04:05:21

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38618314

buddy_ekb

Гость

Alexandr Zlobinесть виртуалка (вмварь)
Alexandr Zlobinвиртуалка - это клон другого сервера.

скажите, пожалуйста, а ваша виртуалка-клон не linked ли случаем?

также интересует, примерно сколько у вас в дропаемой базе таблиц и индексов.

...

Рейтинг:

0 / 0

18.04.2014, 09:30:00

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38618398

Alexandr Zlobin

Гость

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/
может тут неправильно?
может есть какой то чек базы, который можно запустить и пусть идет себе ?

...

Рейтинг:

0 / 0

18.04.2014, 10:25:50

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619214

Alexandr Zlobin

Гость

я удалять базы пробовал от суперпользователя postgres
попробовал его сделать ownerом на удаляемую базу - не помогло (

...

Рейтинг:

0 / 0

18.04.2014, 20:03:35

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619276

Alexandr Zlobin

Гость

добавил лог

log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement = 'all'

буду думать далее

...

Рейтинг:

0 / 0

18.04.2014, 21:52:04

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619281

Alexandr Zlobin

Гость

пофигу... ничего нужного не обнаружил, дроп опять висит

в логе:

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;

...

Рейтинг:

0 / 0

18.04.2014, 22:03:53

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619359

Alexandr Zlobin

Гость

попробовал установить postgres заново с rpm - не помогло.
есть еще какие то идеи? помогите, плиз неделю уже мучаюсь.

...

Рейтинг:

0 / 0

19.04.2014, 04:49:41

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619463

дык думать надо

Гость

Alexandr Zlobinпопробовал установить postgres заново с rpm - не помогло.
есть еще какие то идеи? помогите, плиз неделю уже мучаюсь.
вы этта, вы CREATE DATABASE на том же инстансе попробуйте. Посмотрите, как оно на DROP новой отреагирует.

а так как в том анеке:
-- сдохли они, ребе.
-- жаль, а у меня ещё столько идей

вы, надеюсь, SELECT * from pg_locks; тоже смотрели в момент "зависания" ?

и да, погоняйте всё это из консоли --т.е. psql, а не из под непойми каких приблуд. может быть вы какой-то notice/warning пропускаете

...

Рейтинг:

0 / 0

19.04.2014, 13:01:13

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619471

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

Alexandr Zlobinпопробовал установить postgres заново с rpm - не помогло.
есть еще какие то идеи? помогите, плиз неделю уже мучаюсь.

1)поробуйте checkpoint; сделать перед drop database и посмотрите сколько времени он займет и не сработает ли drop database после этого

2)попробуйте сделать пустую базу и drop ее

3)во время drop откройте еще одну консоль к базе и проверьте что нет НИКАКИХ соединений с той базой которую вы пробуете drop

...

Рейтинг:

0 / 0

19.04.2014, 13:17:56

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619659

Alexandr Zlobin

Гость

1 CREATE DATABASE\drop еще не делал, сделаю уже после праздников, но была еще одна тестовая, размером в 100 мб - удалилась мгновенно

2 SELECT * from pg_locks; -это вроде не выполнял - проверю тоже после праздников , делал во время удаления SELECT * FROM pg_stat_activity; - и кроме дропа -ничего не висит, напомню что пробовал и при полностью отключённой сети, + машина вычищена - никаких сервисов кроме системных и постгреса на ней нет
3 checkpoint; -проверю позже, отпишусь о результатах
4 и делал таки изначально не тулзами, а с консоли. я как уже говорил - не дба, а админ, и вроде не криворукий, но с таким столкнулся впервые и уже просто интересно докопаться до истины и причин.

варнингов никаких нет, начинает выполняться дроп, взлетает загрузка проца до 100% (одного ядра) и все, и длится до бесконечности.. (

из варнингов - только то что кидал выше в логе, при дебаг режиме логирования..

есть еще нюанс - пробовал сделать дамп базы основной, с рабочего сервера, в sql скрипт.
вылезло такое, на штук 8 таблиц, из 400..:
pg_dump90: WARNING: owner of table "auth" appears to be invalid
pg_dump90: WARNING: owner of table "time_t" appears to be invalid
pg_dump90: WARNING: owner of table "report" appears to be invalid

хотя дамп делаю от ownerа базы. в дропаемой базе еще не проверял, но и удалять то пробовал от суперпользователя postgres, по идее должно быть пофигу, но вдруг влияет?

...

Рейтинг:

0 / 0

19.04.2014, 22:11:27

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38619712

Maxim Boguk

Участник

Откуда: Melbourne, Австралия

Сообщения: 5 148

Рейтинг: 0 / 0

Alexandr Zlobin1 CREATE DATABASE\drop еще не делал, сделаю уже после праздников, но была еще одна тестовая, размером в 100 мб - удалилась мгновенно

2 SELECT * from pg_locks; -это вроде не выполнял - проверю тоже после праздников , делал во время удаления SELECT * FROM pg_stat_activity; - и кроме дропа -ничего не висит, напомню что пробовал и при полностью отключённой сети, + машина вычищена - никаких сервисов кроме системных и постгреса на ней нет
3 checkpoint; -проверю позже, отпишусь о результатах
4 и делал таки изначально не тулзами, а с консоли. я как уже говорил - не дба, а админ, и вроде не криворукий, но с таким столкнулся впервые и уже просто интересно докопаться до истины и причин.

варнингов никаких нет, начинает выполняться дроп, взлетает загрузка проца до 100% (одного ядра) и все, и длится до бесконечности.. (

из варнингов - только то что кидал выше в логе, при дебаг режиме логирования..

есть еще нюанс - пробовал сделать дамп базы основной, с рабочего сервера, в sql скрипт.
вылезло такое, на штук 8 таблиц, из 400..:
pg_dump90: WARNING: owner of table "auth" appears to be invalid
pg_dump90: WARNING: owner of table "time_t" appears to be invalid
pg_dump90: WARNING: owner of table "report" appears to be invalid

хотя дамп делаю от ownerа базы. в дропаемой базе еще не проверял, но и удалять то пробовал от суперпользователя postgres, по идее должно быть пофигу, но вдруг влияет?

комманда drop database - фактически просто удаление директории с файлами базы
поэтому ей совершенно пофигу на то какая структура у удаляемой базы и что в ней лежит...

не пофигу ей в общем случае только на три вещи
1)на открытые коннекты к базе
2)на возможность сделать checkpoint перед этим
3)на возможность удалить директорию с файлами базы

1)Давайте вы на всякий случай приведете вывод select * from pg_stat_activity;
сделанный из ТОЙ ЖЕ консоли где вы будете сразу после выполнять комманду drop database (причем сделанный сразу перед тем как делать drop database... т.е. чтобы между select * from pg_stat_activity; не было перерыва в N минут).

2)про checkpoint я вам уже написал

3)а вот еще проверьте утилизацию диска на виртуалхе (iostat -x -d -k 60 в течении 10 минут) и приведите сюда что оно на этот счет пишет... в что еще более важно посмотрите на утилизацию диска на хост системе... у вас там виртуалка случайно не на дифференциальный (или как он там завется) диск залита? Я что то склоняюсь к мысле что проблема скорее всего именно с удалением директории с базой.

Если не поможет прийдется вам изучать команду strace (и хорошо если не команду gdb) и смотреть что собственно происходит.
Так как ничего подобного за свои 15 лет работы с PostgreSQL я не видел и не представляю (на уровне исходного кода базы) в чем может быть еще причина того что операция не выполняется кроме вышеприведенных 3х пунктов.

...

Рейтинг:

0 / 0

20.04.2014, 05:06:40

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38620945

Alexandr Zlobin

Гость

Maxim BogukAlexandr Zlobin1 CREATE DATABASE\drop еще не делал, сделаю уже после праздников ....

, но была еще одна тестовая, размером в 100 мб - удалилась мгновенно
2 SELECT * from pg_locks; -это вроде не выполнял - проверю тоже после праздников , делал во время удаления SELECT * FROM pg_stat_activity; - и кроме дропа -ничего не висит, напомню что пробовал и при полностью отключённой сети, + машина вычищена - никаких сервисов кроме системных и постгреса на ней нет
3 checkpoint; -проверю позже, отпишусь о результатах

1)Давайте вы на всякий случай приведете вывод select * from pg_stat_activity; ...

сделанный из ТОЙ ЖЕ консоли где вы будете сразу после выполнять комманду drop database (причем сделанный сразу перед тем как делать drop database... т.е. чтобы между select * from pg_stat_activity; не было перерыва в N минут).
2)про checkpoint я вам уже написал
3)а вот еще проверьте утилизацию диска на виртуалхе (iostat -x -d -k 60 в течении 10 минут) и приведите сюда что оно на этот счет пишет... в что еще более важно посмотрите на утилизацию диска на хост системе... у вас там виртуалка случайно не на дифференциальный (или как он там завется) диск залита? Я что то склоняюсь к мысле что проблема скорее всего именно с удалением директории с базой.
Если не поможет прийдется вам изучать команду strace (и хорошо если не команду gdb) и смотреть что собственно происходит.
Так как ничего подобного за свои 15 лет работы с PostgreSQL я не видел и не представляю (на уровне исходного кода базы) в чем может быть еще причина того что операция не выполняется кроме вышеприведенных 3х пунктов.

Итак - поехали:
1 create database new; drop database new; checkpoint; - все подряд выполнились менее чем за минуту
2 сразу после чекпоинта,
в одной консоли готовая команда дропа базы, готовая но не запущенная, в нескольких других:
SELECT * from pg_locks;

Код: sql

1.
2.
3.
4.
5.
6.

template1=# SELECT * from pg_locks;
  locktype  | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid  |      mode       | granted
------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------+-----------------+---------
 virtualxid |          |          |      |       | 3/3        |               |         |       |          | 3/3                | 4097 | ExclusiveLock   | t
 relation   |        1 |    10985 |      |       |            |               |         |       |          | 3/3                | 4097 | AccessShareLock | t
(2 rows)

SELECT * FROM pg_stat_activity;

Код: sql

1.
2.
3.
4.
5.
6.
7.

template1=# SELECT * FROM pg_stat_activity;
 datid |  datname  | procpid | usesysid | usename  | application_name | client_addr | client_port |         backend_start         |          xact_start           |          query_start          | waiting |          current_query
-------+-----------+---------+----------+----------+------------------+-------------+-------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------------------
     1 | template1 |    4064 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:37.803065+01 |                               | 2014-04-21 19:52:30.323342+01 | f       | <IDLE>
     1 | template1 |    4097 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:45.548596+01 | 2014-04-21 19:54:50.583245+01 | 2014-04-21 19:54:50.583245+01 | f       | SELECT * FROM pg_stat_activity;
     1 | template1 |    4131 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:55.389752+01 |                               |                               | f       | <IDLE>
(3 rows)

iostat -x -d -k 60

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 3.02 2.74 5.47 0.99 181.43 14.92 60.77 0.20 31.44 9.64 6.23
sda1 2.95 2.74 5.47 0.99 181.15 14.92 60.76 0.20 31.47 9.65 6.23
sdb 0.21 0.00 0.07 0.00 1.12 0.00 31.89 0.00 0.09 0.09 0.00
sdb1 0.14 0.00 0.06 0.00 0.81 0.00 27.39 0.00 0.07 0.07 0.00
sdc 0.44 0.31 0.25 0.22 3.26 2.15 22.92 0.01 17.83 12.73 0.60
sdc1 0.38 0.31 0.24 0.22 2.95 2.15 22.10 0.01 18.17 12.96 0.60

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.22 0.07 0.33 5.40 2.20 38.00 0.00 3.62 2.67 0.11
sda1 0.00 0.22 0.07 0.33 5.40 2.20 38.00 0.00 3.62 2.67 0.11
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.07 0.73 0.88 0.37 9.27 4.40 21.87 0.01 5.76 5.37 0.67
sdc1 0.07 0.73 0.88 0.37 9.27 4.40 21.87 0.01 5.76 5.37 0.67

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 4.27 3.64 0.07
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 4.27 3.64 0.07
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.42 0.00 0.32 0.00 2.93 18.53 0.00 1.32 0.32 0.01
sdc1 0.00 0.42 0.00 0.32 0.00 2.93 18.53 0.00 1.32 0.32 0.01

далее запускаю дроп, и смотрю далее выводы команд, между первыми и текущими
SELECT * from pg_locks; SELECT * FROM pg_stat_activity; - не более 10 сек, делал их по 3 подряд, на всяк случай

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

template1=# SELECT * FROM pg_stat_activity;
 datid |  datname  | procpid | usesysid | usename  | application_name | client_addr | client_port |         backend_start         |          xact_start           |          query_start          | waiting |          current_query
-------+-----------+---------+----------+----------+------------------+-------------+-------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------------------
     1 | template1 |    4064 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:37.803065+01 | 2014-04-21 19:54:51.802093+01 | 2014-04-21 19:54:51.802093+01 | f       | DROP DATABASE jiradb_v4;
     1 | template1 |    4097 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:45.548596+01 | 2014-04-21 19:54:53.402978+01 | 2014-04-21 19:54:53.402978+01 | f       | SELECT * FROM pg_stat_activity;
     1 | template1 |    4131 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:55.389752+01 |                               |                               | f       | <IDLE>
(3 rows)

template1=# SELECT * FROM pg_stat_activity;
 datid |  datname  | procpid | usesysid | usename  | application_name | client_addr | client_port |         backend_start         |          xact_start           |          query_start          | waiting |          current_query
-------+-----------+---------+----------+----------+------------------+-------------+-------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------------------
     1 | template1 |    4064 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:37.803065+01 | 2014-04-21 19:54:51.802093+01 | 2014-04-21 19:54:51.802093+01 | f       | DROP DATABASE jiradb_v4;
     1 | template1 |    4097 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:45.548596+01 | 2014-04-21 19:54:56.554082+01 | 2014-04-21 19:54:56.554082+01 | f       | SELECT * FROM pg_stat_activity;
     1 | template1 |    4131 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:55.389752+01 |                               |                               | f       | <IDLE>
(3 rows)

template1=# SELECT * FROM pg_stat_activity;
 datid |  datname  | procpid | usesysid | usename  | application_name | client_addr | client_port |         backend_start         |          xact_start           |          query_start          | waiting |          current_query
-------+-----------+---------+----------+----------+------------------+-------------+-------------+-------------------------------+-------------------------------+-------------------------------+---------+---------------------------------
     1 | template1 |    4064 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:37.803065+01 | 2014-04-21 19:54:51.802093+01 | 2014-04-21 19:54:51.802093+01 | f       | DROP DATABASE jiradb_v4;
     1 | template1 |    4097 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:45.548596+01 | 2014-04-21 19:55:24.024867+01 | 2014-04-21 19:55:24.024867+01 | f       | SELECT * FROM pg_stat_activity;
     1 | template1 |    4131 |       10 | postgres |                  |             |          -1 | 2014-04-21 19:49:55.389752+01 |                               |                               | f       | <IDLE>
(3 rows)

Код: 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.

template1=# SELECT * from pg_locks;
   locktype    | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid  |        mode         | granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------+---------------------+---------
 virtualxid    |          |          |      |       | 3/10       |               |         |       |          | 3/10               | 4097 | ExclusiveLock       | t
 virtualxid    |          |          |      |       | 2/7        |               |         |       |          | 2/7                | 4064 | ExclusiveLock       | t
 object        |        0 |          |      |       |            |               |    1262 | 16390 |        0 | 2/7                | 4064 | AccessExclusiveLock | t
 relation      |        0 |     1232 |      |       |            |               |         |       |          | 2/7                | 4064 | AccessShareLock     | t
 relation      |        0 |     1214 |      |       |            |               |         |       |          | 2/7                | 4064 | RowExclusiveLock    | t
 relation      |        1 |    10985 |      |       |            |               |         |       |          | 3/10               | 4097 | AccessShareLock     | t
 relation      |        0 |     1262 |      |       |            |               |         |       |          | 2/7                | 4064 | RowExclusiveLock    | t
 transactionid |          |          |      |       |            |    1461424556 |         |       |          | 2/7                | 4064 | ExclusiveLock       | t
(8 rows)

template1=# SELECT * from pg_locks;
   locktype    | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid  |        mode         | granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------+---------------------+---------
 virtualxid    |          |          |      |       | 2/7        |               |         |       |          | 2/7                | 4064 | ExclusiveLock       | t
 object        |        0 |          |      |       |            |               |    1262 | 16390 |        0 | 2/7                | 4064 | AccessExclusiveLock | t
 relation      |        0 |     1232 |      |       |            |               |         |       |          | 2/7                | 4064 | AccessShareLock     | t
 relation      |        0 |     1214 |      |       |            |               |         |       |          | 2/7                | 4064 | RowExclusiveLock    | t
 relation      |        1 |    10985 |      |       |            |               |         |       |          | 3/11               | 4097 | AccessShareLock     | t
 relation      |        0 |     1262 |      |       |            |               |         |       |          | 2/7                | 4064 | RowExclusiveLock    | t
 transactionid |          |          |      |       |            |    1461424556 |         |       |          | 2/7                | 4064 | ExclusiveLock       | t
 virtualxid    |          |          |      |       | 3/11       |               |         |       |          | 3/11               | 4097 | ExclusiveLock       | t
(8 rows)

template1=# SELECT * from pg_locks;
   locktype    | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid  |        mode         | granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+------+---------------------+---------
 virtualxid    |          |          |      |       | 2/7        |               |         |       |          | 2/7                | 4064 | ExclusiveLock       | t
 virtualxid    |          |          |      |       | 3/12       |               |         |       |          | 3/12               | 4097 | ExclusiveLock       | t
 object        |        0 |          |      |       |            |               |    1262 | 16390 |        0 | 2/7                | 4064 | AccessExclusiveLock | t
 relation      |        0 |     1232 |      |       |            |               |         |       |          | 2/7                | 4064 | AccessShareLock     | t
 relation      |        0 |     1214 |      |       |            |               |         |       |          | 2/7                | 4064 | RowExclusiveLock    | t
 relation      |        1 |    10985 |      |       |            |               |         |       |          | 3/12               | 4097 | AccessShareLock     | t
 relation      |        0 |     1262 |      |       |            |               |         |       |          | 2/7                | 4064 | RowExclusiveLock    | t
 transactionid |          |          |      |       |            |    1461424556 |         |       |          | 2/7                | 4064 | ExclusiveLock       | t
(8 rows)

+ вывод iostat - пока делал письмо - он висел, привожу весь:

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.02 0.18 0.33 1.07 14.00 0.00 3.33 2.75 0.05
sda1 0.00 0.08 0.02 0.18 0.33 1.07 14.00 0.00 3.33 2.75 0.05
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.70 0.13 0.33 1.40 4.13 23.71 0.00 2.32 1.75 0.08
sdc1 0.00 0.70 0.13 0.33 1.40 4.13 23.71 0.00 2.32 1.75 0.08

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.36 0.64 0.01
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.36 0.64 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.10 0.00 0.23 0.00 1.33 11.43 0.00 1.93 0.29 0.01
sdc1 0.00 0.10 0.00 0.23 0.00 1.33 11.43 0.00 1.93 0.29 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.25 0.00 0.23 0.00 1.93 16.57 0.00 1.29 0.86 0.02
sda1 0.00 0.25 0.00 0.23 0.00 1.93 16.57 0.00 1.29 0.86 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.62 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.62 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.27 0.00 1.40 10.50 0.00 1.00 0.50 0.01
sda1 0.00 0.08 0.00 0.27 0.00 1.40 10.50 0.00 1.00 0.50 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.50 0.31 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.50 0.31 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.73 0.82 0.01
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.73 0.82 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.38 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.38 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 4.18 2.36 0.04
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 4.18 2.36 0.04
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.88 0.44 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.88 0.44 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 2.36 1.73 0.03
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 2.36 1.73 0.03
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.48 0.00 0.45 0.00 3.73 16.59 0.00 9.15 7.04 0.32
sdc1 0.00 0.48 0.00 0.45 0.00 3.73 16.59 0.00 9.15 7.04 0.32

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.10 0.00 0.22 0.00 1.27 11.69 0.00 1.23 0.69 0.01
sda1 0.00 0.10 0.00 0.22 0.00 1.27 11.69 0.00 1.23 0.69 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.44 0.31 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.44 0.31 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.20 0.00 1.13 11.33 0.00 0.67 0.50 0.01
sda1 0.00 0.08 0.00 0.20 0.00 1.13 11.33 0.00 0.67 0.50 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.69 0.44 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.69 0.44 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.55 1.00 0.02
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.55 1.00 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.06 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.06 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.45 0.73 0.01
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.45 0.73 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.00 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.00 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.64 0.91 0.02
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.64 0.91 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.62 0.50 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.62 0.50 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.18 0.00 0.25 0.00 1.73 13.87 0.00 1.13 0.73 0.02
sda1 0.00 0.18 0.00 0.25 0.00 1.73 13.87 0.00 1.13 0.73 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.81 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.81 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.27 0.00 1.40 10.50 0.00 1.56 0.50 0.01
sda1 0.00 0.08 0.00 0.27 0.00 1.40 10.50 0.00 1.56 0.50 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.81 0.44 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.81 0.44 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.82 1.09 0.02
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.82 1.09 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.75 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.75 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.55 0.91 0.02
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.55 0.91 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.62 0.69 0.02
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.62 0.69 0.02

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.36 0.64 0.01
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.36 0.64 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.45 0.00 0.35 0.00 3.20 18.29 0.00 4.33 3.43 0.12
sdc1 0.00 0.45 0.00 0.35 0.00 3.20 18.29 0.00 4.33 3.43 0.12

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.10 0.00 0.22 0.00 1.27 11.69 0.00 1.31 0.69 0.01
sda1 0.00 0.10 0.00 0.22 0.00 1.27 11.69 0.00 1.31 0.69 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.44 0.44 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.44 0.44 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.20 0.00 1.13 11.33 0.00 1.42 1.00 0.02
sda1 0.00 0.08 0.00 0.20 0.00 1.13 11.33 0.00 1.42 1.00 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.69 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.69 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.55 0.91 0.02
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 1.55 0.91 0.02
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.69 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.69 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 9.09 8.36 0.15
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 9.09 8.36 0.15
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.38 0.31 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.38 0.31 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 2.82 2.09 0.04
sda1 0.00 0.08 0.00 0.18 0.00 1.07 11.64 0.00 2.82 2.09 0.04
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.44 0.44 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 2.44 0.44 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.20 0.00 0.23 0.00 1.73 14.86 0.00 2.29 1.29 0.03
sda1 0.00 0.20 0.00 0.23 0.00 1.73 14.86 0.00 2.29 1.29 0.03
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.50 0.38 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.50 0.38 0.01

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.08 0.00 0.27 0.00 1.40 10.50 0.00 1.25 0.56 0.01
sda1 0.00 0.08 0.00 0.27 0.00 1.40 10.50 0.00 1.25 0.56 0.01
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.25 0.31 0.01
sdc1 0.00 0.38 0.00 0.27 0.00 2.60 19.50 0.00 1.25 0.31 0.01

- первые три, до удаления отсюда убрал - это продолжение.
+ после команды дроп - возросла нагрузка на проц - скрин в аттаче, кстати, только обратил внимание что висят какие то "пустышки" непонятные, в htop они видны c низкими пидами и приоритетами. буду еще с этим разбираться.

относительно нагрузки винта - по хост машине загрузки нету, и в топе процессы с обменом в 1 мегабайт сек. когда же распаковывал базу в виртуалке - в топе хост машины была виртуалка, с обменом в 30 мегабайт сек... сейчас нагрузка только на проц...

strace -придется - будем учить )

...

Рейтинг:

0 / 0

21.04.2014, 23:25:36

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38621248

Alexandr Zlobin

Гость

А можно ли удалить папку с базой вручную -а потом в постгресе? может это поможет?

...

Рейтинг:

0 / 0

22.04.2014, 11:34:22

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38621344

LeXa NalBat

Участник

Откуда: Москва

Сообщения: 2 843

Рейтинг: 0 / 0

странно, что процесс постгреса в топе называется "startup"

вот выдача команды ps у меня:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

postgres 29063  0.0  0.0 158004  2764 ?        S    Apr18   0:06 /usr/pgsql-9.2/bin/postmaster -p 5432 -D /var/lib/pgsql/9.2/data
postgres 29065  0.0  0.0 117752  1104 ?        Ss   Apr18   0:00  \_ postgres: logger process                                        
postgres 29067  0.1  0.0 158108  4772 ?        Ss   Apr18   5:34  \_ postgres: checkpointer process                                  
postgres 29068  0.0  0.0 158004  1492 ?        Ss   Apr18   0:05  \_ postgres: writer process                                        
postgres 29069  0.0  0.0 158004  1328 ?        Ss   Apr18   1:23  \_ postgres: wal writer process                                    
postgres 29070  0.0  0.0 158832  2508 ?        Ss   Apr18   0:03  \_ postgres: autovacuum launcher process                           
postgres 29071  0.0  0.0 117884  1320 ?        Ss   Apr18   0:11  \_ postgres: stats collector process                               
postgres 15243  0.2  0.0 159292  4576 ?        Ss   12:21   0:00  \_ postgres: postgres postgres [local]  DROP DATABASE

покажите ваш список процессов

...

Рейтинг:

0 / 0

22.04.2014, 12:25:51

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38621355

Alexandr Zlobin

Гость

LeXa NalBat,
тут постгрес был скомпилен а не rpmкой ставился, + смотрю htop ом.
может из за этого
запскается стандартным стартап скриптом.

...

Рейтинг:

0 / 0

22.04.2014, 12:29:23

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38621490

а зачем

Гость

Alexandr ZlobinА можно ли удалить папку с базой вручную -а потом в постгресе? может это поможет?а зачем. поставьте новый инстанс, в него поднимите только то, что нужно

или то, что нужно - это очень много, а то, что не дропается - мало ?

вы скопируйте вашу дата-директорию ("кластер") куда-нть. там права все выставьте на пользователя, из под которого пж стартует(postgres по умолчанию), и с неё , с копии кластера и стартуйте. заодно это будет болванка для ваших экспериментов с "а можно ли".

...

Рейтинг:

0 / 0

22.04.2014, 13:38:17

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38621526

Alexandr Zlobin

Гость

[quot а зачем]Alexandr Zlobinвы скопируйте вашу дата-директорию ("кластер") куда-нть. там права все выставьте на пользователя, из под которого пж стартует(postgres по умолчанию), и с неё , с копии кластера и стартуйте. заодно это будет болванка для ваших экспериментов с "а можно ли".

собственно с этим и експерементирую

...

Рейтинг:

0 / 0

22.04.2014, 14:00:38

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38621540

buddy_ekb

Гость

Alexandr ZlobinА можно ли удалить папку с базой вручную -а потом в постгресе? может это поможет?

Можно и поможет.

Просто интересно, почему у вас там такое.

...

Рейтинг:

0 / 0

22.04.2014, 14:08:31

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38621564

Alexandr Zlobin

Гость

buddy_ekbAlexandr ZlobinА можно ли удалить папку с базой вручную -а потом в постгресе? может это поможет?
Можно и поможет.
Просто интересно, почему у вас там такое.
Именно!
самому интересно )
думаю параллельно сделаю тестовую базу с бекапа (скл скрипт) и уже буду с ней работать (надеюсь там будет все ок), а на этой буду далее разбираться.

...

Рейтинг:

0 / 0

22.04.2014, 14:26:39

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38622110

LeXa NalBat

Участник

Откуда: Москва

Сообщения: 2 843

Рейтинг: 0 / 0

может быть это? Postgres Streaming Replication lagging, using lots of CPU and little I/O

...

Рейтинг:

0 / 0

22.04.2014, 19:22:21

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38622149

Alexandr Zlobin

Гость

LeXa NalBat,

возможно, но я так и не понял вылечили ли и как?

...

Рейтинг:

0 / 0

22.04.2014, 19:51:39

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38622210

Alexandr Zlobin

Гость

у меня shared memory маленький.
вот последний (текущий) конфиг, который был уже запущен на момент тестов выше (с иостатом и тд)

temp_buffers = 1024MB
max_stack_depth = 2MB # min 100kB
wal_level = hot_standby # minimal, archive, or hot_standby
checkpoint_timeout = 10min
# (change requires restart)
archive_command = 'cp %p /opt/postgresql_9/xlog_archive/%f' # command to use to archive a logfile segment
# number of seconds; 0 disables
cpu_tuple_cost = 0.001
cpu_index_tuple_cost = 0.0005
log_destination = 'stderr'
logging_collector = on # Enable capturing of stderr and csvlog
log_directory = '../log' # directory where log files are written,
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
log_rotation_size = 100MB # Automatic rotation of logfiles will
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
# debug5
# info
log_connections = off
log_line_prefix = '%m:*:%r:**:%d:***:%u:****: ' # special values:
log_statement = 'none' # none, ddl, mod, all
autovacuum_max_workers = 100 # max number of autovacuum subprocesses
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'en_US.UTF-8' # locale for monetary formatting
lc_numeric = 'en_US.UTF-8' # locale for number formatting
lc_time = 'en_US.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.english'
escape_string_warning = off
default_statistics_target = 50 # pgtune wizard 2014-04-21
maintenance_work_mem = 120MB # pgtune wizard 2014-04-21
constraint_exclusion = on # pgtune wizard 2014-04-21
checkpoint_completion_target = 0.9 # pgtune wizard 2014-04-21
effective_cache_size = 1408MB # pgtune wizard 2014-04-21
work_mem = 10MB # pgtune wizard 2014-04-21
wal_buffers = 8MB # pgtune wizard 2014-04-21
checkpoint_segments = 16 # pgtune wizard 2014-04-21
shared_buffers = 480MB # pgtune wizard 2014-04-21
max_connections = 100 # pgtune wizard 2014-04-21

переменные внутренние, как в мускуле системные variables - могут влиять? как их проверить?
такое чуство будто что то подкручено для пк с оперативой в 18 гб (ранее стояло на физ сервере)

...

Рейтинг:

0 / 0

22.04.2014, 21:27:00

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38623628

Alexandr Zlobin

Гость

Подскажите, в какую сторону еще можно копнуть, что бы понять, почему не дропается база?
еще мне не нравится то, что проц загружен, а память нет... может это натолкнет на какие то мысли

...

Рейтинг:

0 / 0

23.04.2014, 19:12:32

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38623957

buddy_ekb

Гость

Alexandr Zlobin,

насколько вам это принципиально знать? если жить без этого никак нельзя, то смотрите в сторону strace/ltrace/systemtap или специалистов по ним, которым вы доверите доступ к своему инстансу.

вообще внешне всё походит на глюк старого самосборного postgresql + набора данных. глюк этот вряд ли представится возможным воспроизвести, поэтому логичнее на него попросту забить.

...

Рейтинг:

0 / 0

24.04.2014, 09:00:49

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38623993

Alexandr Zlobin

Гость

возможно и проблема самосборного.
но я пробовал поставить из рпмки - и подсовывал папку data - тоже самое.
есть большое подозрение что битые данные - следовательно хотелось бы с этим разобраться.
опять же, размер самой крупной базы -190гб, а выгруженный дамп в скрипт - около 130...

...

Рейтинг:

0 / 0

24.04.2014, 09:25:11

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38624040

buddy_ekb

Гость

Alexandr Zlobinесть большое подозрение что битые данные - следовательно хотелось бы с этим разобраться.

проверить это сравнительно просто - создайте свежий инстанс, залейте в него дамп и попытайтесь дропнуть базу.

допустим, база дропнется нормально. что вам даст знание того, что глюк происходит из-за повреждённых данных?

...

Рейтинг:

0 / 0

24.04.2014, 10:04:15

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38624041

Alexandr Zlobin

Гость

[quot buddy_ekb]Alexandr Zlobinчто вам даст знание того, что глюк происходит из-за повреждённых данных?
буду искать как пофиксить на оригинальном хосте, так как остановить его увы нельзя.

...

Рейтинг:

0 / 0

24.04.2014, 10:05:26

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38624055

buddy_ekb

Гость

Alexandr Zlobinбуду искать как пофиксить на оригинальном хосте, так как остановить его увы нельзя.

возникает сразу несколько непонятных моментов:
- откуда известно, что глюк присутствует на оригинальном хосте? есть вполне себе вероятность, что данные могли быть искажены в процессе копирования и глюк проявляется только в вашей виртуалке.
- даже если глюк присутствует на оригинальном хосте, то зачем там дропать используемую базу? а если она неиспользуемая, то пусть себе лежит до очередного запланированного простоя, после чего её можно будет спокойно удалить "вручную".
- если хочется перфекционизма и полной уверенности в отсутствии любых глюков на оригинальном хосте, то планируйте dump/upgrade/reload. иначе зачем всё это?

...

Рейтинг:

0 / 0

24.04.2014, 10:17:32

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38624151

Alexandr Zlobin

Гость

buddy_ekbпланируйте dump/upgrade/reload. иначе зачем всё это?
возможно придется.
зачем - хочу понимать причину, почему это произошло, хоть и на виртуалке, и знать как избежать в будущем.

...

Рейтинг:

0 / 0

24.04.2014, 11:00:23

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38625857

Alexandr Zlobin

Гость

вобщем, есть одно подозрение, может кто подскажет как лечить правильно:
папка data сделана с помощью pg_start_backup('label', true);
но последующих логов - нету
чекпоинты которые показывает pg_controldata - позже чем дата метки и логов между ними нету.
может ли при дропе идти проверка на целостность? потому и тормозит?
и как восстановить имея только папку дата без логов ?

...

Рейтинг:

0 / 0

25.04.2014, 15:18:16

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38626178

Alexandr Zlobin

Гость

перенес на физ машину, по процам - слабее чем ноут, по винтам - с рейдом, правда слабым
не знаю как - но удалил!!! все норм.! пытаюсь повторить на виртуалке.

...

Рейтинг:

0 / 0

25.04.2014, 18:47:14

| Ответить | Цитировать | Написать

drop database (около 2 гб ) длится уже более 10 часов

#38626200

Alexandr Zlobin

Гость

удалил!!!
сделалось почти мгновенно!!

поигрался на физ машине (убил почти 2 дня), и тут получилось, повторил на виртуалке - все прошло!
не знаю что конкртенто помогло, но еще раз распаковал папку с данными, несмотря на отсутсвие логов - сбросл по меткам лог,
потом
REINDEX SYSTEM template1;

после этого с тестовой базой, утилитами:
reindexdb -e -U postgres -d testdb
vacuumdb -v -z -e -U postgres -d testdb
(последнего не дождался, а на болшой базе -вакум не делал а первого не дождался, в обеих случах давал командам поработать минут 30-40)

и на физ машине дропнул утилитой, а в виртуалке - она не захотела работать - писала ошибку ниже, что не делал (
dropdb -U postgres testdb
dropdb: could not connect to database postgres: FATAL: the database system is starting up
но зашел в постгрес - и от туда удалилось нормально.

вывод - побились данные...

...

Рейтинг:

0 / 0

25.04.2014, 19:17:57

| Ответить | Цитировать | Написать

48 сообщений из 48, показаны все 2 страниц

все

Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / drop database (около 2 гб ) длится уже более 10 часов

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=53&tid=1998720]:	0ms
get settings:	12ms
get forum list:	20ms
check forum access:	5ms
check topic access:	5ms
track hit:	217ms
get topic data:	12ms
get forum data:	3ms
get page messages:	102ms
get tp. blocked users:	2ms
others:	227ms

total:	605ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы