Потенційний метод №1 - F_DROP_CACHES
Я знайшов метод з 2012 року, який обговорює запропонований патч до ядра Linux у цій поштовій нитці під назвою: Re: [RFC Patch] fs: реалізувати кеш-пам’яті для кожного файлу .
витяг
Cong> Це проектний патч реалізації кеш-файлів падіння файлів.
Цікаво. То чи можу я це зробити поза процесом? Я SysAdmin, тому мій POV не помічає, знаходить і виправляє проблеми з продуктивністю, коли система перебуває під тиском.
Cong> It introduces a new fcntl command F_DROP_CACHES to drop
Cong> file caches of a specific file. The reason is that currently
Cong> we only have a system-wide drop caches interface, it could
Cong> cause system-wide performance down if we drop all page caches
Cong> when we actually want to drop the caches of some huge file.
Як я можу сказати, скільки кешу використовується файлом? І який вплив це на ефективність роботи при запущеній системі? І що нам купує цей патч, оскільки я вважаю, що VM вже має скидати кеші, коли система потрапляє під тиск пам'яті ...
Cong> Нижче наведено невеликий тестовий випадок для цього виправлення:
Нитка включає в себе як тестовий зразок, так і власне патч до декількох файлів у ядрі Linux, що додає додаткову функцію для fs/drop_caches.c
виклику drop_pagecache_file(struct file *filp)
. Потім ця функція стає доступною за допомогою інструменту frontend fnctl.c
за допомогою команди F_DROP_CACHES
. Цей виклик викликає цю функцію:
file_drop_caches(filp, arg);
Який обробляє випадання всіх кешів, пов'язаних із даним файлом. З файлу include/linux/mm.h
:
void file_drop_caches(struct file *filp, unsigned long which);
Так це можна використовувати?
Я не знайшов жодних доказів того, що цей патч ніколи не пробивався в основне сховище коду Linux, тому ця опція виявиться доступною, лише якщо ви готові самостійно перекомпілювати ядро Linux.
Потенційний метод №2 - Використання дд
У цьому ж потоці інший користувач згадує зовсім іншу методологію, яка використовує dd
.
Нижче наведено уривок із цього електронного листа
Це корисна функціональність. Хоча це вже не забезпечено
POSIX_FADV_DONTNEED
? Цю функціональність було додано до GNU dd (8.11) рік тому .
Ось приклади цього виправлення:
Порадьте залишити кеш для всього файлу
$ dd if=ifile iflag=nocache count=0
Переконайтеся, що кеш-пам'ять для всього файлу
$ dd of=ofile oflag=nocache conv=notrunc,fdatasync count=0
Видаліть кеш частини файлу
$ dd if=ifile iflag=nocache skip=10 count=10 of=/dev/null
Потокові дані використовуються лише кешем для читання вперед
$ dd if=ifile of=ofile iflag=nocache oflag=nocache
Тестуючи це
Я не був на 100% позитивний, як перевірити це, але придумав наступний підхід.
зробіть файл 100 Мб
$ dd if=/dev/urandom of=sample.txt bs=100M count=1
Доступ до файлів трасування за допомогою fatrace
$ sudo fatrace | grep sample.txt
запустіть, top
щоб ми могли відслідковувати використання пам’яті.
$ top
відкрити файл, відзначити кількість вільної пам'яті зараз. Зверніть увагу fatrace
на файл sample.txt
.
$ cat sample.txt > /dev/null
скиньте файл з пам'яті, відзначте кількість вільної пам'яті зараз. Зверніть увагу на результат fatrace
.
$ sudo dd of=/home/saml/tst/162600/sample.txt \
oflag=nocache conv=notrunc,fdatasync count=0
Приклад
У терміналі №1:
$ dd if=/dev/urandom of=sample.txt bs=100M count=1
1+0 records in
1+0 records out
104857600 bytes (105 MB) copied, 7.37996 s, 14.2 MB/s
$ ls -l sample.txt
-rw-rw-r--. 1 saml saml 104857600 Oct 17 22:54 sample.txt
У терміналі №2:
$ top
...
KiB Mem: 7968336 total, 6900956 used, 1067380 free, 267080 buffers
...
У терміналі №3:
$ sudo fatrace | grep sample.txt
Тепер відкрийте файл sample.txt
і відзначте об’єм оперативної пам’яті. У терміналі №1.
$ cat sample.txt > /dev/null
У терміналі №2:
KiB Mem: 7968336 total, 7011896 used, 956440 free, 267336 buffers
Зверніть увагу на вихід fatrace
терміналу №3:
cat(25940): R /home/saml/tst/162600/sample.txt
cat(25940): R /home/saml/tst/162600/sample.txt
cat(25940): RC /home/saml/tst/162600/sample.txt
Тепер видаліть файл з оперативної пам’яті в терміналі №4:
$ sudo dd of=/home/saml/tst/162600/sample.txt \
oflag=nocache conv=notrunc,fdatasync count=0
Зверніть увагу на вихід fatrace
в терміналі №2:
dd(26229): O /home/saml/tst/162600/sample.txt
dd(26229): CW /home/saml/tst/162600/sample.txt
Зверніть увагу на оперативну пам'ять в терміналі №3:
KiB Mem: 7968336 total, 6908364 used, 1059972 free, 267364 buffers
Отже, здавалося б, все те, що було використано файлом в оперативній пам'яті, звільнене.
Потенційний метод №3 - пітон-фадвіс
Завдяки коментарю @frostchutz, є ще один інструмент, сценарій Python, названий [pyadvise][4]
який забезпечує набагато простіший інтерфейс, ніж вищевказані dd
методи. Цей сценарій використовує той самий posix_fadvise(2)
інтерфейс.
Приклад
$ sudo pyadvise --help
Usage:
pyadvise [options] [FILE]..
Options:
-h, --help show this help message and exit
-w, --willneed The specified files will be accessed in the near future
-s, --sequential The application expects to access the specified files
sequentially (with lower offsets read before higher ones)
-d, --dontneed The specified files will not be accessed in the near
future
-r, --random The specified files will be accessed in random order
-o, --noreuse The specified files will be accessed only once. Under
Linux, this operation is a no-op; see contrib/copyfileobj-
fadvise.py in the python-fadvise source tree for an
example on how to achieve approximately the same effect
-n, --normal Indicates that the application has no advice to give about
its access pattern for the specified files. If no advice
is given for an open file, this is the default assumption
-v, --verbose Explain what is being done
І якщо ми повторимо вищевказаний тест і використаємо pyadvise
замість dd
:
$ pyadvise -d /home/saml/tst/162600/sample.txt
Я помітив ідентичне падіння споживаної оперативної пам’яті, як і раніше, коли я користувався dd
.