Настройка кэша для 8Гб Озу

cat /path/to/database.db > /dev/null

Примерно это, только более интеллектуально делают üreadehead, readehead и прочие.

s/ручками/скриптиками/g

*for the name of moon

Значит всетаки придется ручками...а так мечталось о том, что уже давно все позаботили :) Будет резиновый рамдиск...выберу чем сделать. Лругих вариантов пока не придумал.

дисковый кеш в линуксе включен по умолчанию. Лучше чем есть, ты не сделаешь.

Легко. Полная копия БД в Озу (всего то 1Гб) и потом слив обработанной обратно на диск в конце рабочего дня. Гараздо лучше чем сейчас есть, никаких данных на жестком и обращений к нему.

а в кошерном постгресе есть, например, настройка shared_buffers

Дааа. Это я пока мечтаю :) Я его сейчас и изучаю потихоньку, и поглядываю на memcached немного. Но это впереди. Пока думал «о, какой крутой ноут, надо попробовать!» :) Код надо будет пилить много на postgres...но переезд уже намечен после изучения и переписи.

а вообще первая же ссылка в гугле http://www.sqlite.org/inmemorydb.html

а вы эта, пишите бд-независимый код. Или в вашем языке нет стандартов работы с базами данных наподобие JDBC/JPA?

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

Ну...в игры я дано отыграл...это я хвастаюся :) Если серьезнее, то да, я и думал кэш настроить «по современному», но как к этому подползать не знаю. Сегодня уже не редкость 2-8 Гб Озу, а система расчитана на древность, хотя некоторый дистры на 64 переходят уже совсем, но вот с остальными частями пока туго...или я не знаю как.

Код придется пилить потому, что в postgres есть SQL запросы (я этот код имел в виду) гараздо более гибкие и емкие чем SQLite. БД небольшая и SQLite вроде хватает, но скорость работы все падает, так как количество генеримых данных на основе БД растет...вот и наметился переезд, несмотря на то, что объем БД небольшой. Специфика SQLite в том, что «обрабатывающий» код приходится писать в самом софте, а в postgres можно будет на SQL все почти сделать.

А вот за это In-Memory Databases спасибо...я как то упустил :) Ноут только купил, глаза разбегаются :)

Блин, вы мне своим советом сорвали весь план на изучение новой БД. Так хоть повод был :)

Вот почему я не нашел эту штуку раньше. В моей реализации (или версии) либы просто нету такого. Перееду на свежую и будет мне счастье. Там к интерфейсу БД в моем коде надо будет добавить три строки. Вопрос закрыт.

К великому сожалению, например, в том же оракле, если писать БД-независимый код и не использовать vendor-specific штуки, то производительность БД ниже среднего...

Как я и говорил. 1 марта этого года внесли изменения в либу, а я давно не следил...как то хватало, только вот теперь мало стало. Добавили реализацию интерфейса к inmemorydb+initializeBackup. Скачал новую, добавил три строки и все залетало. Немного отладки (хотя где там в трех то строках :)) и все же попробую postgres поковырять...давно хочу.