Полностью отказаться от обращения к жесткому диску

@cerevra · Регистрация: 29.01.2013

Студворк — интернет-сервис помощи студентам

привет
есть небольшая база. правил postgresql.conf:
shared_buffers = 512MB
work_mem = 32MB
fsync = off
logging_collector = off

Есть острое желание, чтобы все хранилось в памяти: работа с жестким была исключена
Это возможно?

ЗЫ как вообще оценить размер базы? бэкап весит 1.8мб

@grgdvo · 14.04.2013, 17:53

как вариант использовать RAM-диск!
НО!!! такое решение существенно понижает надежность!!! Падение сервера и ВСЕ! только бакапы спасут.

По каким признакам оценивала, что база тормозит?
Может еще не все средства оптимизации исчерпаны?

@cerevra · 14.04.2013, 18:05 **[ТС]**

на надежность - фиолетово. курсач: работает ПО минуты 3, в работе обращается к базе. надо разогнать донельзя )) ибо до этого - ПО держало все в памяти, работало чуть быстрее

RAM-disk - не вариант. все должно работать на ПК под Win

в ходе работы диспетчер задач пишет, что процесс postgresql вываливает на жесткий до 3 мб/с
это совершенно не нужно. база дропается и наполняется заново при каждом запуске софтины: не надо ужасаться - иначе только юзать скрипт, который потрет все таблицы, индексы, функции и секвансы. так надо

идеи? )

magirus · 14.04.2013, 18:08

Сообщение от cerevra

все должно работать на ПК под Win

а что рамдиски под вин не существуют? или я чего то не допонял?

@cerevra · 14.04.2013, 18:11 **[ТС]**

имелось в виду, что любой желающий, а не только обладатели RAM-дисков, могли фапать на получившийся продукт

@grgdvo · 15.04.2013, 17:28

Сообщение от cerevra

ибо до этого - ПО держало все в памяти, работало чуть быстрее

может ничего не получится... ибо в вашем случае добавляется прослойка в виде движка СУБД, которое разбирает запрос, выделяет буфера, занимается выполнением запросов и т.д.

не очень понятно откуда трафик 3Мб/с, если вы сказали размер бакапа базы всего 1,8Мб? Или это только структура без данных? По умолчанию pg_dump делает текстовый бакап.

@cerevra · 15.04.2013, 17:33 **[ТС]**

Сообщение от grgdvo

может ничего не получится... ибо в вашем случае добавляется прослойка в виде движка СУБД, которое разбирает запрос, выделяет буфера, занимается выполнением запросов и т.д.

нынче софт работает перебором всех возможных вариантов ( в лоб ). надежда была на оптимизированный движок postgresql

Сообщение от grgdvo

не очень понятно откуда трафик 3Мб/с

да мне самому интересно, откуда такой трафик народился... Структура бд - инсертов в форматированном виде строк на 200. А 1,8 - это бэкап структуры + данные

в принципе, могу вывалить в тему структуру, бэкап и файл настроек сервера. мало ли... вдруг интересно кому...

@grgdvo · 15.04.2013, 17:48

У вас перебор случайно не "тупое" соединение нужных таблиц в JOIN (или под FROM) ?
Это как бы не айс совсем для базы! Попробуйте индексы пристроить что ли или попытайтесь как-то связать таблицы. Хотя полный перебор он и в африке полный перебор. Вряд ли получится быстрее, чем написать, например, 10 вложенных for'ов для известной структуры данных.

Посмотрите еще вот: http://www.postgresql.org/docs... ource.html
Там есть процесс background writer (18.4.5), кто пишет на диск. Может что и пригодится

@cerevra · 15.04.2013, 21:51 **[ТС]**

Сообщение от grgdvo

У вас перебор случайно не "тупое" соединение нужных таблиц в JOIN (или под FROM) ?

ну... эм

SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SELECT foo.rss_id
        FROM 
        (SELECT rss_param.rss_id 
        FROM rss, rss_param, enum_rv
        WHERE rss.rtp_id = 2
        AND rss.id = rss_param.rss_id
        AND rss_param.id = 1
        AND rss_param.value = enum_rv.id 
        AND enum_rv.vv = 'Пришел' ) AS foo,
        rss_param, int_rv
        WHERE foo.rss_id = rss_param.rss_id
        AND rss_param.id = 2
        AND rss_param.value = int_rv.id 
 
        ORDER BY int_rv.vv
         USING > 
        LIMIT 1 ;

типичный запрос... научите, как надо =)

@cerevra · 16.04.2013, 01:27 **[ТС]**

допил до такого вот состояния (в приложении)

самое забавное: нашел, что надо выставить в настройках, чтобы общение к диску максимум составляло 0,1мб/с
synchronous_commit = off
fsync = off

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

@cerevra · 16.04.2013, 01:43 **[ТС]**

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

@grgdvo · 22.04.2013, 00:23

Если еще актуально?!

Я восстановился из вашего бакапа. С одним исключением: создал пользователя testuser и базу данных test. Работа под суперпользователем postgres не приветствуется.

Могу привести лог восстановления, но сербезных ошибок не было. Так... ворнинги на индексы по умолчанию для первичных ключей и на grant/revoke на отсутствие привилегий.

Скопировал запрос из поста и выполнил в pgadmin3... Получил время выполнения запроса = 83 ms (миллисекунды). Никаких танцов с бубнами вокруг сервера не было, вообще все это делал на старом ноуте (core2). Вот тоже самое из psql

Code
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
user@note ~ $ psql -h localhost -U testuser -w test
Пароль пользователя testuser: 
psql (9.2.1)
Введите "help", чтобы получить справку.
 
test=> SELECT foo.rss_id
test->         FROM 
test->         (SELECT rss_param.rss_id 
test(>         FROM rss, rss_param, enum_rv
test(>         WHERE rss.rtp_id = 2
test(>         AND rss.id = rss_param.rss_id
test(>         AND rss_param.id = 1
test(>         AND rss_param.VALUE = enum_rv.id 
test(>         AND enum_rv.vv = 'Пришел' ) AS foo,
test->         rss_param, int_rv
test->         WHERE foo.rss_id = rss_param.rss_id
test->         AND rss_param.id = 2
test->         AND rss_param.VALUE = int_rv.id 
test->  
test->         ORDER BY int_rv.vv
test->          USING > 
test->         LIMIT 1 ;
 rss_id 
--------
   9615
(1 строка)

Время вполне приличное. Может где-то в другом месте проблема? Или у меня не воспроизводится?

@cerevra · 22.04.2013, 00:58 **[ТС]**

актуально. вы все воспроизвели верно
проблема в этом месте. если заменить место в работе разрабатываемого ПО на алгоритм без использования БД, то работает все в 4 раза быстрее. хотел разогнать. у меня вот corei7 и 12 гб озу: запрос выполняется 45мс - ожидалось, что будет быстрее =) увы и ах. я уже смирился с тем, что работает медленнее

проблема вот еще в чем: когда я создаю индекс (hash), например, по полю vv таблицы enum_rv, запрос выполняется 550мс... хотелось бы понять, в чем я не прав. ибо научрук тут мне не помощник =(

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

заранее спасибо

@grgdvo · 22.04.2013, 16:56

Критическими с точки зрения производительности в запросе вот эти строки

SQL
1
2
3
AND rss_param.VALUE = enum_rv.id
...
AND rss_param.VALUE = int_rv.id

Эти операции занимают практически 90% времени, если верить плану выполнения запроса (EXPLAIN).
Если я правильно понял суть таблиц, то VALUE в зависимости от типа RSS_PARAM присваивается из других разных таблиц (ENUM_RV, INT_RV, ...).

@cerevra · 22.04.2013, 17:24 **[ТС]**

ну да, все верно

SQL
1
2
enum_rv.id
int_rv.id

на эти поля уже созданы индексы по умолчанию (эти поля - первичные ключи, все-таки)

SQL
1
rss_param.VALUE

индексы по этому столбцу вообще никакой реакции не дали...

SQL
1
2
CREATE INDEX myind ON rss_param USING hash (VALUE);
CREATE INDEX myind ON rss_param (VALUE);

нет идей почему?

@grgdvo · 23.04.2013, 16:02

Сообщение от cerevra

нет идей почему?

Потому что индекс не влияет на операцию Hash, которая строится для enum_rv и int_rv и rss_param.
Hash - это построение промежуточной таблицы из исходной таблицы (с учетом условия, например для enum_rv только для записей, которые vv='Пришел'), которая потом будет соединяться с rss_param. Получается, что, чтобы соединить enum и rss_param, нужно как минимум два цикла: первый строит хэш, а второй по этому хэшу делает соединение.

Выход... ну может быть пойти от вашего неСУБД алгоритма, посмотреть как там выполняется подобная операция и попытать подогнать.

Новые блоги и статьи Все статьи Все блоги /
Символьное дифференцирование igorrr37 13.02.2026 / * Программа принимает математическое выражение в виде строки и выдаёт его производную в виде строки и вычисляет значение производной при заданном х Логарифм записывается как: (x-2)log(x^2+2) -. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»
SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .	Установка Qt-версии Lazarus IDE в Debian Trixie Xfce volvo 10.02.2026 В общем, достали меня глюки IDE Лазаруса, собранной с использованием набора виджетов Gtk2 (конкретно: если набирать текст в редакторе и вызвать подсказку через Ctrl+Space, то после закрытия окошка. . .

@cerevra 0 / 0 / 0 Регистрация: 29.01.2013 Сообщений: 17

	Полностью отказаться от обращения к жесткому диску 13.04.2013, 17:48. Показов 9555. Ответов 15 Метки нет (Все метки) привет есть небольшая база. правил postgresql.conf: shared_buffers = 512MB work_mem = 32MB fsync = off logging_collector = off Есть острое желание, чтобы все хранилось в памяти: работа с жестким была исключена Это возможно? ЗЫ как вообще оценить размер базы? бэкап весит 1.8мб 0

@grgdvo 1264 / 978 / 384 Регистрация: 02.09.2012 Сообщений: 3,021
	14.04.2013, 17:53
	как вариант использовать RAM-диск! НО!!! такое решение существенно понижает надежность!!! Падение сервера и ВСЕ! только бакапы спасут. По каким признакам оценивала, что база тормозит? Может еще не все средства оптимизации исчерпаны? 0

@cerevra 0 / 0 / 0 Регистрация: 29.01.2013 Сообщений: 17
	14.04.2013, 18:05 [ТС]
	на надежность - фиолетово. курсач: работает ПО минуты 3, в работе обращается к базе. надо разогнать донельзя )) ибо до этого - ПО держало все в памяти, работало чуть быстрее RAM-disk - не вариант. все должно работать на ПК под Win в ходе работы диспетчер задач пишет, что процесс postgresql вываливает на жесткий до 3 мб/с это совершенно не нужно. база дропается и наполняется заново при каждом запуске софтины: не надо ужасаться - иначе только юзать скрипт, который потрет все таблицы, индексы, функции и секвансы. так надо идеи? ) 0

@cerevra 0 / 0 / 0 Регистрация: 29.01.2013 Сообщений: 17
	14.04.2013, 18:11 [ТС]
	имелось в виду, что любой желающий, а не только обладатели RAM-дисков, могли фапать на получившийся продукт 0

@grgdvo 1264 / 978 / 384 Регистрация: 02.09.2012 Сообщений: 3,021
	15.04.2013, 17:48
	У вас перебор случайно не "тупое" соединение нужных таблиц в JOIN (или под FROM) ? Это как бы не айс совсем для базы! Попробуйте индексы пристроить что ли или попытайтесь как-то связать таблицы. Хотя полный перебор он и в африке полный перебор. Вряд ли получится быстрее, чем написать, например, 10 вложенных for'ов для известной структуры данных. Посмотрите еще вот: http://www.postgresql.org/docs... ource.html Там есть процесс background writer (18.4.5), кто пишет на диск. Может что и пригодится 0

@cerevra 0 / 0 / 0 Регистрация: 29.01.2013 Сообщений: 17
	22.04.2013, 00:58 [ТС]
	актуально. вы все воспроизвели верно проблема в этом месте. если заменить место в работе разрабатываемого ПО на алгоритм без использования БД, то работает все в 4 раза быстрее. хотел разогнать. у меня вот corei7 и 12 гб озу: запрос выполняется 45мс - ожидалось, что будет быстрее =) увы и ах. я уже смирился с тем, что работает медленнее проблема вот еще в чем: когда я создаю индекс (hash), например, по полю vv таблицы enum_rv, запрос выполняется 550мс... хотелось бы понять, в чем я не прав. ибо научрук тут мне не помощник =( вот таблица rss, например, формируется в самом начале и не меняется больше... какой индекс можно завести для нее, чтобы приведенный выше запрос заработал быстрее? заранее спасибо 0