Насколько опасно кеширование средствами операционной системы Linux?
В новом проекте хочу реиспользовать один из своих опытов, но был в свое время напуган одной экспертизой. Поэтому хотел бы уточнить мнение общественности.
Итак, в свое время столкнулся с медленной работой PostgresSQL, а именно с таблицей, к которой идут редкие обращения. В этом случае PG "разогревается", и на первые запросы ответ может готовиться десятками секунд. Знаю, что на крупных проектах некоторые практикуют специальные скрипты "разогрева" базы с утра, но мне такой вариант не очень нравится.
У меня был опыт, когда я "собирал" выборки из базы данных, и просто клал их на сервер в виде файла. После этого, когда юзер запрашивал данные, я просто брал готовый файл с файловой системы и отдавал его. Скорость была феноменальной, и измерялась десятками, а не сотнями миллисекунд.
Но однажды мне сказали, что так делать нельзя, поскольку такой подход убивает жесткий диск за счет множественных обращений к файловой системе. Мне это запало в мозг, и отсюда вопрос - это действительно так?
Инженерно мне кажется, что нет:
1. Файловая система кеширует файлы, и они не должны каждый раз перезапрашиваться из базы.
2. Многие управляющие скрипты (типа cat, grep, ps) многими используются в bash-скриптах, и никто не думает о рисках для файловой системы.
3. Кеширование HTML в Ruby работает примерно так же - хранение файлов в файловой системе.
Про диски - чушь это всё. Диски давно уже умирают по причинам куда более прозаичным (брак, удар, температура), чем износ.
И даже современные ssd вопреки всеобщему мнению от записи мрут очень редко (это надо очень постараться, чтобы ssd-ку убить записями).
Но всё же греть кеши скриптами правильнее, если у вас данные в базе меняются.
ssd частая перезапись убьет, а как я понимаю, у вас она не настолько уж и частая. А что бы убить так hdd - это нужно постараться.
С другой стороны в самом постгрессе есть масса вариантов кеширования выборки, выборки особо критичные можно вообще в памяти хранить. Можно настроить кэш файловой системы, что бы файлы еще какое-то время в памяти весели и снизить обращение к ней.
Вариантов массы.
p.s. тут немного непонятно, что вы имеете ввиду про утилиты cat/grep/ps... Они просто работают с текстовыми стримами, и им глубоко плевать, к файловой системе обращаться, или стрим к ним уже из памяти приходит.
В базе около 25 млн. записей. Когда я смотрю Explain, я четко вижу при первом запуске тысячи обращений к диску, на втором запуске - сотни, на третьем все читается из памяти и запрос выполняется за сотни миллисекунд. Поскольку к какому фрагменту обращаться будут - неизвестно, закешировать что-то нет смысла, а для переноса всей базы в память надо более 40 гигов.
Под grep и прочим, я только понимаю, что и они читаются очень часто с диска, то есть если бы частое чтение с диска убивало бы его, то простой запуск этих утилит, скажем, из крона, по логике тоже должно было бы убивать диск. Или по другому. Мой способ может убить диск не сильнее, чем обычные бинарные linux утилиты.
@Stan_1, чтение с диска никак не влияет на ресурс HDD или SSD. Запись влияет на последнее. Для HDD больше влияет фрагментация данных (и то только на производительность).
глупости какие то
так рассуждать любой звонок с телефона убивает его давайте звонить не будет
в любом случае ваше обращение к файлу намного проще и бережнее чем обращение к бд
