Как мы нашли дешевый способ увеличить оперативную память для работы InvariVision

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

Для понимания сути проблемы мы начали вводить по одному поисковые ядра по 2.4GB и следили за изменением в производительности системы. Мы добавляли ядра до тех пор пока большая часть ядер не была выгружена из оперативной памяти. Мы понимали, что SSD работает гораздо медленнее, чем оперативная память. И чем больше мы будем задействовать swap, тем менее производительной будет система. Поэтому нужно было оптимизировать процесс работы с данными — сделать рабочий набор данных максимально компактным, чтобы он полностью помещался в RAM, а сам набор менять как можно реже.

Наиболее произвольно к памяти обращался алгоритм оптимизации ветвей поискового индекса, который обходил все данные. Чтобы избавиться от этого мы применили приём “dirty flag”. Это работало следующим образом: после модификации ветви поискового дерева устанавливалась метка “dirty”, чтобы затем  оптимизация осуществлялась не по всему дереву, а только в модифицированных ветвях.

Чтобы уменьшить рабочую область памяти, мы убрали все лишние данные из поисковых структур, насколько это было возможно, и сгруппировали данные в порядке обращения к ним. Это позволило на 20% снизить использование поиском оперативной памяти. Доступ к данным памяти стал проще, а хранение более компактным. Мы смогли не только уменьшить использование оперативной памяти, но и ускорить запись и чтение данных поисковых ядер с диска в два раза.

Но оставались еще одна проблема, которую надо было решить прежде, чем переходить на swap. Дело в том, что отказ любого из SSD дисков в RAID (где есть swap space) мог привести к сбою приложения или ОС. Полностью обезопасить систему от таких отказов мы не могли. Единственный выход — максимально снизить ущерб от потери данных и повреждений ПО, если это все-таки произойдет.

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

Решением проблемы оптимизации оперативной памяти мы начали заниматься с 21 сентября 2016 года, а уже 13 декабря обновили систему со swap. В будущем мы планируем создать свой специализированный вариант взаимодействия с SSD, который будет работать эффективнее, чем стандартный системный swap, так как будет учитывать специфику работы ядер и адаптирован специально под наши нужды.