LINUX.ORG.RU

Можно ли в линуксе настраивать кеширование?

 


0

1

У друга мускул тормозит и при этом целиком влезает в RAM. Можно конечно создавать на ramfs файл, форматировать его, класть туда файлы БД, но чего то слишком много слоев. Может можно создать маленький раздел на hdd для БД как обычно, форматнуть как обычно, положить туда файлы, но настроить кеш таким образом, чтобы линукс сразу сообщал об успешной записи мускулу, никогда не сбрасывал записанное на диск и никогда не выгружал однажды кешированное для чтения?



Последнее исправление: ZugDuk (всего исправлений: 1)

Можно и таким Макаркой: tmpfs (в fstab можно указать размер, какой хошь) примонтировать куды хошь, а в mysql указать хранение. Запись в это место идёт при старте из чего надо (пишем скрипт). Если надо, то и оттуда можно сливать, да. На истинно верное решение не претендую.

Deleted
()

мускул тормозит

В чем проявляется? Я бы посмотрел iotop, может дело и не в жд, а в настройках mysql или кривых запросах.

ddidwyll ★★★★
()

никогда не сбрасывал записанное на диск

И при аварийном завершении все данные пойдут прахом? Так то он сам должен рулить своим кэшем.

ddidwyll ★★★★
()
Ответ на: комментарий от ddidwyll

Объясню, почему нельзя просто юзать tmpfs и положить туда файлы бд. Это слейв сервер, есть еще мастер. Но слейв не может подняться с нуля после падения. Ему нужно знать место откуда восстанавливаться. В этом случае мастер шлет разницу. Это место слейв всегда знает, если пользуется обычным диском. Механизм оптимизирован разработчиками мускула и работает. Но если внезапно падает слейв в оперативе, то там ноль и ничего подняться не может. Нужен бекап. Если делать бекап из tmpfs rsync-ом, то возникает запаздывание. Я тут тонкостей не знаю, но друг сказал, что не попрет rcync (сервер не поднимется из такой копии). Единственный верный вариант - это бекап с помощью снапшота. В этом случае это будет эквивалент стандартной работы на диске и ситуации - выдернули сервер из розетки. Вот для снапшота и нужна цепочка слоев tmpfs -> файл -> мапинг этого файла средствами dmsetup -> ext4fs -> собственно файлы БД.

ZugDuk
() автор топика
Ответ на: комментарий от ZugDuk

Но цепочка чрезмерно большая. 100% в ней будет падение производительности (а все делается ради нее). Гораздо лучше, чтобы кеш линукса (ближайший к мускулу слой) настроить таким образом, чтобы он отвечал мускулу сразу мол все записалось, ну и выдавал ответы на запросы чтения из RAM, а не с диска.

ZugDuk
() автор топика
Ответ на: комментарий от ZugDuk

Хм, я знаю что нельзя просто положить бд в тмпфс. Как-то костылил две базы sqlite, одна в памяти, вторая на диске, писало в обе, читало из быстрой, но это так, ради спортивного интереса, что-то серьёзное так не сделать.

ddidwyll ★★★★
()

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

Evgueni ★★★★★
()
Последнее исправление: Evgueni (всего исправлений: 2)
Ответ на: комментарий от ZugDuk

чтобы он отвечал мускулу сразу мол все записалось

Поставь контроллер с BBU. Writeback cache без батарейки - ССЗБ.

Minona ★★☆
()
Ответ на: комментарий от Deleted

tmpfs при наличии SSD - это только если есть 146 GB RAM и не смог придумать зачем

anonymous
()
Ответ на: комментарий от Deleted

Большие файлы это ещё было б понятно, но с мелких-то ему что станет?

anonymous
()

Заменить мускуль на постгрес, который не считает себя умнее ядра, а позволяет ему заниматься кэшированием

annulen ★★★★★
()
Ответ на: комментарий от annulen

Спасибо, уже всё как всегда написано ;)

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.