Недавно тут сидел на нескольких защитах дипломных работ на Факультете Компьютерных Наук ВШЭ. Это занятие жутко неблагодарное, очень устаёшь всех слушать 4 часа, а ещё недавно мой организм дал мне понять, что я всего лишь кожаный мешок, и оно совсем не помогло его восстановлению. Тем не менее, были хорошие работы, которые понравились
мне, и студенты разрешили о них поделиться:
1.
Ковальков Дмитрий. Текст работы недоступен, Дмитрий не захотел публиковать текст из-за причин оформления :)
Тема:
Исследование существующих решений консенсуса на устойчивость к отказам в fsync
Это отличное исследование и эксперименты со статьей 2020 года "
Can Applications Recover from fsync Failures?", которая смотрела на падения систем, если вдруг не смог сработать fsync, когда ядру говорят, что пора данные на диск сбрасывать, а тот не смог принять это. И если система неправильно обрабатывает такие падения, то возможны серьёзные последствия.
Последствия:
ломается leader election в Zookeeper. Дмитрий провёл исследование c помощью CuttleFS, написал
патч к Zookeeper и выложил скрипты на
github. Учитывая, что даже Jepsen не смог найти такие падения, я думаю, что при желании Дмитрий может превратить своё исследование в полноценный фреймворк. При защите у меня было ощущение, что Дмитрий как будто сам не осознал, какой у этого потенциал, поэтому говорю — огромный :)
2-3.
Хасанова Алия.
Родионов Антон.
Темы: хоть были их две, то я опишу их суммарно
Анализ использования полей протобуфа
Так как я был руководитель этих дипломов, то немного предыстории. У меня давно в голове крутилась идея, что fault tolerance можно использовать как способ агрессивных оптимизаций. А именно если есть какой-нибудь MapReduce, то jobs/workers должны быть устойчивы к падениям и это нормальный ход вещей. А что если мы попытаемся оптимизировать достаточно агрессивно и поймём походу если надо, что были слишком агрессивны и просто перезапустим в более безопасном режиме? Пользователь не заметит и если мы обеспечим хороший rate успеха, то и ресурсы сэкономим.
В Гугле и Яндексе протобуфы читаются везде и всегда в таких сервисах, и если читаются протобуфы, а используются один-два поля, то много информации просто уходит в никуда. Так как протобуфы статические, то есть два подхода: анализировать сам код или трекать динамически. Алия делала первое, а Антон второе.
В первом подходе мы помечали все getters протобуфа специальными метками и удаляли их с помощью
garbage collector в линкере, а во втором писали плагин, чтобы собирать всю информацию по ходу исполнения. Получался профиль, а что делать с этим профилем — решать уже пользователям, кто захочет перекомпилировать без этих полей, а кто напишет свой парсер и будет парсить только часть. В MapReduce можно падать, если прочитали поле, которое не в профиле и обновлять профиль.
Оказалось, что у меня на работе около 50-80% полей не используются из-за всяких рекурсивных зависимостей и вообще предварительно всё неплохо ускоряется. И это прям нужно было
многим, кто хочет следить по безопасности, какие поля читаются, а кто хочет трекать просто большие поля и их размеры и сэмплить их. А кто вообще хочет запретить использовать некоторые протобуфы.
Я в итоге сделал свою версию и протолкнул до open source, но, думаю, ещё десять раз поменяем интерфейс
https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/field_access_listener.h. Заработает ли идея с агрессивностью, не знаю, надеюсь, что да, но интуиция говорит, что это очень тяжело.
Вообще, хоть я и сам закончил ФКН 2 года назад, было интересно вести дипломы и писать рецензии людям, при правильной мотивации студентам интересно это делать. К сожалению, это очень сильно выматывает, потому что студенты в основном начинают всё делать в марте-апреле и размазать не получается. Сейчас я не хочу ничего брать на следующий год, ибо пока я всё ещё один могу сделать больше за этот промежуток, чем студенты. Это и точка роста для меня — уметь делегировать, чтобы суммарно больше получалось, но как же тяжело идёт у меня работа с людьми...
