PostgreSQL 8.3: улучшение производительности в разы

>$ ./a.out >Failed to write into file, errno: 22.

Собственно, тоже самое происходит и при любом другом размере блока записи, в том числе и кратном 512.

FC7, ext3.

> что такое "страница БД" в терминологии постгреса.

Минимальной атом физического чтение/записи диска. 8кБ

> 2maxcom: а Вы настроили этот параметр? 8.2 оптимайзер запросов стал очень чувствителен к нему.

Да, спасибо. У нас выставлено 1.6Gb при общем размере оперативки в 4Gb.Судя по выводу комманты free у нас под кеш используется ~2Gb

>$ ./a.out >Failed to write into file, errno: 22.

А решением оказалось выравнивание записываемого буфера на 512 байт...

Так что таки да, через direct-io можно писать в обчне файлы.

> Нет, я открываю обычный файл на запись с флагом O_DIRECT, делаю запись и получаю ошибку :)

Анонимчег, я вижу ты ВООБЩЕ не читаешь мануалы. В линуксе O_DIRECT требует i/o блоками размером pagesize и aligned buffer.

а, ок, вижу - не безнадежен :)

> Некоторые изменения должны неплохо ускорить скорость выполнения некоторых запросов движка lor'а.

Тебе вдалбливали ещё 9 лет назад, что для форума в плане скорости идеален mysql. Он реально минимум вдвое более производителен. Но ты же крутой "специалист", и не ищешь лёгких путей ;)

>Анонимчег, я вижу ты ВООБЩЕ не читаешь мануалы. В линуксе O_DIRECT требует i/o блоками размером pagesize и aligned buffer.

Вообще-то не page size, а только 512 байт, но идею ты уловил.

> Тебе вдалбливали ещё 9 лет назад, что для форума в плане скорости идеален mysql. Он реально минимум вдвое более производителен. Но ты же крутой "специалист", и не ищешь лёгких путей ;)

Движек lor'а сделан так, как было интересно тогда его программировать.

>> Анонимчег, я вижу ты ВООБЩЕ не читаешь мануалы. В линуксе O_DIRECT требует i/o блоками размером pagesize и aligned buffer.

> Вообще-то не page size, а только 512 байт, но идею ты уловил.

Хе-хе. Братег, я не программер, поэтому проблемы реализации direct io в линуксе для меня несколько второстепенны. А мануалы таки почитывай. Реже придется газировать лужи.

scott/tiger

>>>Размер блока ФС должен быть равен или быть кратно меньше странице БД (8кБ default)

>> что такое "страница БД" в терминологии постгреса.

> Минимальной атом физического чтение/записи диска. 8кБ

Тьфублин, я в выражении "быть кратно меньше" как-то пропустил "меньше" и сижу голову ломаю :-)

>>> Это как же? :) Direct-io работает только с блочными устройствами, так что запись в обычные файлы _всегда_ идет через кеш страниц.

>>Братег-анонимчег, ты тоже читаешь мануалы 12 летней давности? :) 

>Нет, я открываю обычный файл на запись с флагом O_DIRECT, делаю запись и получаю ошибку :)

Потому что документацию не читаешь. И на errno смотреть иногда надо. Оно тебе Invalid argument давало.

Вот так работает (ext2 и reiserfs).

#define _GNU_SOURCE

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
#include <unistd.h>

char block[4096] __attribute__((__aligned__(4096))) = "This is a test\n";
char block2[4096] __attribute__((__aligned__(4096)));

int main(int argc, char *argv[])
{
	int fd, err;

	fd = open("/tmp/test", O_CREAT | O_RDWR | O_DIRECT);
	if (fd < 0) {
		perror("Failed to open file with O_DIRECT");
		return -1;
	}

	err = write(fd, block, sizeof(block));
	if (err < 0) {
		perror("Failed to write into file");
		return -1;
	}

	err = lseek(fd, 0, SEEK_SET);
	if (err < 0) {
		perror("lseek");
		return -1;
	}

	err = read(fd, block2, sizeof(block));
	if (err < 0) {
		perror("Failed to read from file");
		return -1;
	}

	puts("All is ok.");
	return 0;
}

Из настоящих серьезных бенчмарков нескольких СУБД есть сравнение MySQL, PostgreSQL и Oracle, выполненное по всем канонам инженерами Sun, новость по-русски на постгресмене: http://postgresmen.ru/news/view/44 по-английски на ITtoolbox: http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-first-...

> Движек lor'а сделан так, как было интересно тогда его программировать.

Хорошо. В таком случае можно поинтересоваться, каким бы был движок ЛОР'а, если бы он планировался к написанию сейчас? Интересна эволюция мышления автора в свете полученного опыта эксплуатации.

> Из настоящих серьезных бенчмарков нескольких СУБД есть сравнение MySQL, PostgreSQL и Oracle, выполненное по всем канонам инженерами

"Наконец-то создатели PostgreSQL смогли доказать то, что ... хорошо
настроенная база данных PostgreSQL не только работает быстрее чем MySQL"
- 8% разницы я насчитал. А стоимость обслуживания...

>А стоимость обслуживания...

Обслуживания чего?

> Хорошо. В таком случае можно поинтересоваться, каким бы был движок ЛОР'а, если бы он планировался к написанию сейчас? Интересна эволюция мышления автора в свете полученного опыта эксплуатации.

Кстати да. Тоже об этом подумал, но почему-то постеснялся спросить.

> Хорошо. В таком случае можно поинтересоваться, каким бы был движок ЛОР'а, если бы он планировался к написанию сейчас? Интересна эволюция мышления автора в свете полученного опыта эксплуатации.

Примерно так же, только на каком-нибудь MVC-framework вроде Spring web-mvc.

В плане базы я бы не стал отказываться от постгресса, поскольку хорошо умею его "готовить". Хотя если framework предоставлял бы хороший базонезависимый ORM-layer, то использовал бы ту базу, которая лучше работает с этим самым framework'ом.

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

Тут такое дело maxcom ...

1 - все ORM'ы тормозят :( Одни мрачно, другие по-божески - но тормозят все.

2- RoRails - синоним не просто тормоза, а тормоза мрачного! На лоровских объёмах его - как барсука от никотина .... :)

>Вот например два запроса, дающих одинаковый результат:

Еще немного поинтересуюсь =) Я бы писал второй вариант и об первом даже не подумал бы, какая цепочка рассуждений поможет составить перейти от второго к первому? или это только с опытом и чутьём приходит?

> Еще немного поинтересуюсь =) Я бы писал второй вариант и об первом даже не подумал бы, какая цепочка рассуждений поможет составить перейти от второго к первому? или это только с опытом и чутьём приходит?

Ну я бы тоже написал сначала первый вариант, а потом глядя на план выполнения думал бы как его можно ускорить. Потому как тут хорошо видно что постгресс фигней занимается. Вместо того чтобы выбрать 10 id и для них уже вытащить сообщения из msgbase, он вытаскивает весь msgbase целиком (порядка 1-2Gb), сортирует его (сохраняя результат во временные файлы на диск, т.к. в память он не влезает), а затем откусывает от него 10 первых записей.

В данном случае вполне сработал бы вариант разбивки запроса на две части - вытаскивание 10 нужных ID, а потом вытаскивание нужных сообщений. С подзапросом тоже самое и получается.

Хотя, это, конечно, специальный синтетический пример - при наличии индекса для сортировки все встает на свои места (и исполняется за микросекунды). В этом случае подзапрос только мешает оптимизатору и второй вариант становится быстрее.

> 1 - все ORM'ы тормозят :( Одни мрачно, другие по-божески - но тормозят все.

Ну да, я тоже не особо верю в ORM

> 2- RoRails - синоним не просто тормоза, а тормоза мрачного! На лоровских объёмах его - как барсука от никотина .... :)

Я думаю его тоже нужно уметь готовить. Хорошее кеширование, думаю, спасет и RoR, и его ORM. Хотя хрен его знает, пока не попробуешь не узнаешь.

>с каких пор fork() стал «безумно дорогим»? на винфак!

Вообще-то само установление соединения сетевого - безумно дорогой вариант.

>Придётся делать два разных дистра.

Положи два файла - они все называются по разному, и будет работать и там и там.

> По тестам sqlite капитально сливает на параллельных запросах.

С рельсами вообще что-то странное происходит - иногда говорит ошибка синтаксиса на рельсовские запросы (когда ошибки никакой нет) рестарт все спасает. Бред.

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

Поэтому неиспользования пула/persistent connection или мультиплексера - убийство производительности на корню. На среднем компьютере без использования вышеупомянутых техник практически невозможно превзойти 50-100 запросов в секунду.

> Ну я бы тоже написал сначала первый вариант

второй

>Rails это тоже интересно, я бы попробовал его на каком-нибудь проекте если было бы время.

Даже не пробуй. Я уже попробовал. Тебе придется стать шефповаром с извращенным вкусом - то есть переписать половину вещей которых рейлс типа умеет - руками. Он иногда такой умный - аж страшно. Например сопротивляется джойну таблицы которая не прописана в маппинге (а там она не может быть прописана по причине наличия хитрой логики) - называется переходим к raw sql. Он M:N нормально автоматически разрулить не может даже промапленный - все приходится ручками ручками. Вебсервисы - вообще отдельный ппц. Те кто ходит и везде расказывает что рельсы чего-то там киллер видать сидят на тяжелых наркотиках.

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

>Поэтому неиспользования пула/persistent connection или мультиплексера - убийство производительности на корню. На среднем компьютере без использования вышеупомянутых техник практически невозможно превзойти 50-100 запросов в секунду.

Ага - это я еще лет 8 назад эспериментально установил:)

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

> Хорошее кеширование, думаю, спасет и RoR, и его ORM.
Несколько раз в блогах "первопроходцев" натыкался на сообщения, что ROR полностью падает при интенсивной нагрузке. Из-за каких-то ошибок в GC.
Возможно уже поправили, но он (Ruby) и без ORM тормозной, а с ORM, боюсь и подавно.

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

> Вообще-то само установление соединения сетевого - безумно дорогой вариант.

Неправда. Особенно на фоне запросов, которые длятся по 20 секунда ;)

Кстати есть у постгреса 'особенность', иногда безобидные запросы длятся примерно 0.5-0.6 секунд, видимо что-то он сбрасывает на диск перед тем, как выполнить. Как можно уменьшить это время?

> у постгреса 'особенность', иногда безобидные запросы длятся примерно 0.5-0.6 секунд, видимо что-то он сбрасывает на диск перед тем, как выполнить. Как можно уменьшить это время?

Как как? известно как - найти причину возникновения этой "особенности" и устранить её.

> езобидные запросы длятся примерно 0.5-0.6 секунд,

Угу. Checkpoint имя этой причине. В 8.3 эта проблема заметно сглажена.

>Неправда. Особенно на фоне запросов, которые длятся по 20 секунда ;)

правда.

> Примерно так же, только на каком-нибудь MVC-framework вроде Spring web-mvc.
> В плане базы я бы не стал отказываться от постгресса, поскольку хорошо умею его "готовить".

Понятно. Ничему так и не научился. По-прежнему пишешь неэффективные
программы, зато в модном стиле...

>По-прежнему пишешь неэффективные программы, зато в модном стиле...

А что - лор тормозит?

>>По-прежнему пишешь неэффективные программы, зато в модном стиле...

>А что - лор тормозит? >r

А что - лор в модом стиле? 8-о

>>Придётся делать два разных дистра.
>Положи два файла - они все называются по разному, и будет работать и там и там.

Двойка обоим ;) Один из вариантов JDBC к SQLite - содержит внутри собственно его реализацию ... нормальные (честные) - тоже есть.

>> По тестам sqlite капитально сливает на параллельных запросах.
>С рельсами вообще что-то странное происходит
>Бред.
>r ***

Э! э! э! - мы же вроде для emmbed. базу искали? А тут -трэды да рельсы ... Для совсем встроенных или для тех кому нужна очень высокая производительность до сих пор ничего BerkeleyDB (SleepyCat) не придумано - но програмить ее - не мёд :-) Оттого народ и любит SQLite - оно хоть и lite, но всё же - SQL !

>ничего BerkeleyDB (SleepyCat)

Уже оракл.

А ну да, r спасибо за уточнение :)

Никак не могу привыкнуть что это - оракал теперь :) Как и иннодб ...

КСТАТЕ! оракалы вона чего напрограммили: "Oracle Berkeley DB Java Edition is a open source, embeddable, transactional storage engine written entirely in Java. Like Oracle Berkeley DB, Oracle Berkeley DB Java Edition executes in the address space of the application, without the overhead of client/server communication. It stores data in the application's native format, so no runtime data translation is required. It provides an easy-to-use, programmatic interface, allowing developers to store and retrieve information quickly, simply and reliably."

http://www.oracle.com/database/berkeley-db/je/index.html

>КСТАТЕ! оракалы вона чего напрограммили:

Это еще слипикет напрограмировал - у них уже это было перед самой покупкой.

Там еще XML хранилище есть.