Есть свежее распределенное хранилище. Кластер уже установлен и готов к вводу в продакшн. Самое время протестировать производительность. Такое тестирование проводится, чтобы понять скорость работы хранилища на практике, оценить адекватность инсталляции и понять его максимальную производительность на старте. В этой статье я поделюсь методологией препродакшн тестирования.

Я приведу несколько примеров принятия решений на разных этапах, но цель этой статьи не охватить все возможные кейсы, а описать методологию тестирования — основные этапы, нюансы процесса и некоторые распространенные ошибки.

Нужно сказать, что больше всего я работал с Ceph, поэтому в основном методология строится исходя из этого опыта, но, если не вдаваться в детали, то подход к тестированию более-менее одинаков для всех распределенных программных хранилищ данных (SDS).

Fast SSDs are getting cheaper every year, but they are still smaller and more expensive than traditional HDD drives. But HDDs have much higher latency and are easily saturated. However, we want to achieve low latency for the storage system, and a high capacity too. There’s a well-known practice of optimizing performance for big and slow devices — caching. As most of the data on a disk is not accessed most of the time but some percentage of it is accessed frequently, we can achieve a higher quality of service by using a small cache.

Server hardware and operating systems have a lot of caches working on different levels. Linux has a page cache for block devices, a dirent cache and an inode cache on the filesystem layer. Disks have their own cache inside. CPUs have caches. So, why not add one more persistent cache layer for a slow disk?

В Linux есть большое количество инструментов для отладки ядра и приложений. Большинство из них негативно сказываются на производительности приложений и не могут быть использованы в продакшене.

There are a lot of tools for debugging kernel and userspace programs in Linux. Most of them have performance impact and cannot easily be run in production environments. A few years ago, eBPF was developed, which provides the ability to trace the kernel and userspace with low overhead, without needing to recompile programs or load kernel modules.

There are now plenty of tools that use eBPF and in this article, we’ll explain how to write your own profiling tool using the PythonBCC library. This article is based on a real issue from the production environment. We’ll walk you through solving the problem and show how existing bcc tools could be used in some cases.

Огромную популярность набирает тема повышения производительности операционных систем и поиска узких мест. В этой статье мы расскажем об одном инструменте для поиска этих самых мест на примере работы блочного стека в Linux и одного случая траблшутинга работы хоста.

Пример 1. Тестовый

Ничего не работает

Тестирование в нашем отделе ― это синтетика на продуктовом железе, а позже ― тесты прикладного ПО. К нам на тестирование поступил диск Intel Optane. Ранее о тестировании дисков Optane мы уже писали в нашем блоге.

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

В сфере устройств хранения данных за последние годы произошли серьёзные изменения: внедряются новые технологии, растут объём и скорость работы дисков. При этом складывается следующая ситуация, в которой узким местом становится не устройство, а программное обеспечение. Механизмы ядра Linux для работы с дисковой подсистемой совершенно не приспособлены к новым, быстрым блочным устройствам.