Вопрос к линуксоидам

Опубликовано пн, 09/11/2009 - 00:30 пользователем larin

Как определить, берётся ли файл из кэша или с диска?

Точнее, нужен список файлов, за, скажем, час, которые читались с диска. Те, которые брались из кэша - не интересуют.
(Да, я понимаю, что все файлы проходят через буфера. Нужны те, кто нагружают диск, как это не назови.)
Из них буду выбирать, кого проще утащить на другой сервер.
А то опять упёрлись в диск, прошлый раз помогло добавление нового, а третий в сервер уже не лезет.
Значит файло уёдет на другую машину. Не знаю только, какое именно. В идеале - которое меняется редко, а читается часто, для упрощения синхронизации.
Список открытых/прочитанных файлов я получил с помощью perl-Linux-Inotify2, но не могу понять, кто из них взят из кэша, а ради кого пришлось диск мучать. Можно, конечно, прикинуть из общих соображений, но что-то меня потянуло на системный подход.

Комментарии

Опубликовано пн, 09/11/2009 - 02:36 пользователем otaku

Может вам просто помочь с оптимизацией раздачи файлов?
А так просто на логи накатить любой анализатор логов который выдаст список самого популярного, а так с сервера с 5 винтами я выжимаю до 800 мегабит на 500-700 одновременных коннектов.

Опубликовано пн, 09/11/2009 - 03:26 пользователем larin

otaku написал:
Может вам просто помочь с оптимизацией раздачи файлов?
А так просто на логи накатить любой анализатор логов который выдаст список самого популярного, а так с сервера с 5 винтами я выжимаю до 800 мегабит на 500-700 одновременных коннектов.

5 винтов SAS или обычных SATA?
что-то у меня два сата тянут не больше ста, и то с трудом.
Может потому, что миллион мелких файлов.

Опубликовано пн, 09/11/2009 - 03:51 пользователем BorLase

larin написал:
Точнее, нужен список файлов, за, скажем, час, которые читались с диска. Те, которые брались из кэша - не интересуют.

а last-access-time разве не поможет? ИМХО, если файл читался с диска - время обновится, если из кеша - останется прежним

Опубликовано пн, 09/11/2009 - 04:32 пользователем Ulenspiegel

Кстати, а чей именно кеш имеется в виду ? У файловой системы - свой, у Apache|Squid - свои, и вот их-то cache hits вполне можно увидеть в соответствующих логах.

Опубликовано пн, 09/11/2009 - 05:37 пользователем Anarchist

Ulenspiegel написал:
Кстати, а чей именно кеш имеется в виду ? У файловой системы - свой, у Apache|Squid - свои, и вот их-то cache hits вполне можно увидеть в соответствующих логах.

Есть мнение, что здесь скорее nginx.
А он, по моим ощущениям (основанным на достаточно беглом знакомстве) документирован... несколько хуже Индейца.

Опубликовано пн, 09/11/2009 - 05:39 пользователем Anarchist

BorLase написал:
а last-access-time разве не поможет? ИМХО, если файл читался с диска - время обновится, если из кеша - останется прежним

Только вот... Сбор такого рода статистики --- дело небыстрое и весьма ресурсоёмкое.

У меня же здесь к тов. Ларину немного другой вопрос: какая файловая система используется? Параметры файловой системы стандартные/умолчательные или она уже оптимизировалась под конкретную ситуацию (с учётом величины нагрузки --- необходимо).

Опубликовано пн, 09/11/2009 - 04:10 пользователем Ян Злобин

Для начала неплохо бы посмотреть какая именно софтина читает файлы. Если просто логически - там что кэш сопоставим с размером диска? Вряд ли, а значит в кэше файлов принципе мало.

Опубликовано пн, 09/11/2009 - 07:46 пользователем otaku

Боюсь что здесь дело в тонкой настройке нгинкса для отдачи файлов.
Юзаю файловую систему xfs, она куда адекватнее работает чем екст3 в некоторых моментах.
От сасов отказался, в силу того что на бесплатном софте могу поиметь большую производительности с сата дисков, да и объемы данных у меня внушительные, ну а так есть файлопомойка с музыкой там тоже куча мелких файлов.

Опубликовано пн, 09/11/2009 - 11:33 пользователем p2004r

larin написал:
Как определить, берётся ли файл из кэша или с диска?

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

Радикально может решить вопрос io дискового только 10й райд. Лучше всего если это будет 6 рабочих дисков + спер диск.

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

Или на этом отдельном сервере живет акселерирующий прокси и объема дисков достаточно что бы закешировать все, а записи книг (на чтение и выкачку) сделаны максимально дружественными к кешированию.

--------------------

Пока писал пришел на ум вариант с SSD диском на который надо залинковать все файлы которые в топе или вообще все (если оно лезет :). На hd оставить только логи и базу, вообщем часто меняющуюся информацию. SSD имеет ноутбучный формат и влезет в корпус :).

Опубликовано пн, 09/11/2009 - 16:14 пользователем p2004r

на опеннете указали на:

---8<-----

http://sourceware.org/systemtap/

в частности http://sourceware.org/systemtap/examples/io/iostats.stp

---8<-----

Опубликовано сб, 14/11/2009 - 22:46 пользователем larin

p2004r написал:

Радикально может решить вопрос io дискового только 10й райд. Лучше всего если это будет 6 рабочих дисков + спер диск.
В принципе файлохранилище может быть расположено в отдельном сервере и выделенным гигабит линком подключено в сервер раздающий контент.
Пока писал пришел на ум вариант с SSD диском на который надо залинковать все файлы которые в топе или вообще все (если оно лезет :). На hd оставить только логи и базу, вообщем часто меняющуюся информацию. SSD имеет ноутбучный формат и влезет в корпус :).

Варианты замечательны своей радикальностью.
Не то чтобы они не приходили мне в голову.
Но как-то не готов я вбухивать десятки тысяч евро в железо.
Нет у Либрусека таких доходов, увы.
Пришлось решать проблему более бюджетными способами - добавил диск и памяти в соседний сервер и перенёс туда часть файлов.
Полегчало.
X