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

ReSQL.ru

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

Гость

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

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

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

Цитировать

Написать

Автор*:

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

Тема*:

Сообщение

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

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

Автор:

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

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

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

Вложение:

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

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

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

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

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

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

23 сообщений из 48, страница 2 из 2

все

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

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

23 сообщений из 48, страница 2 из 2

все

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

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

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

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

start [/forum/topic.php?fid=53&msg=38622149&tid=1998720]:	0ms
get settings:	10ms
get forum list:	18ms
check forum access:	3ms
check topic access:	3ms
track hit:	43ms
get topic data:	10ms
get forum data:	3ms
get page messages:	80ms
get tp. blocked users:	1ms
others:	195ms

total:	366ms

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