Комментарии 15
Вот вроде бы и тема должна быть интересная - сейчас расскажут как ускорить PostgreSQL в джва раза, и какой-то неизвестный трюк покажут!
Но это ж OTUS. Чемпионы по копированию банальщины. Ну ребята, ну опять...
Если какой-то автор в своем блоге пишет заметку с названием "интересный трюк", то не стоит тупо копировать это. Для заголовка на Хабр хотя бы надо раскрыть: "подмена системного вызова через LD_PRELOAD". Ясно и лаконично, снимает большинство вопросов, те кто знает - просто не идут читать.
Статья 2016 года. 7 лет - это довольно большой срок. Я не говорю что все поменялось, но стоит такое указывать в комментарии в начале.
По содержанию статьи - претензии уже не к переводчику, а к автору. Но для качественного оформления стоит все-таки добавить комментарии в начале. Автор увлеченно аннотирует что сейчас расскажет трюк с ускорением программ на порядок, но внезапно, просто рассказывает про подмену системного вызова. Как он ускорил postgres - ну понятно что через этот "трюк", но скорее всего, там было переписана довольно существенная часть с вызовом системных функций - может быть кэширование или еще что..
Недавно на кафедре баз данных TUM я работал над интересной низкоуровневой библиотекой на языке С — tssx, заменяющей в любом приложении взаимодействие через сокеты на быструю передачу данных через разделяемую память. С нашей библиотекой Postgres работает более чем в два раза быстрее, а некоторые программы даже на порядок быстрее. В основе библиотеки лежит трюк с
LD_PRELOAD, о котором я и расскажу в этой статье.
Первый обзац, последнее предложение.
Похоже написать критикующий комментарий гораздно проще, чем прочесть преамбулу.
К тому же если вы достаточно опытен в работе с linux, то по названию итак было очевидно о чем статья.
И-Интрига? Простите, не настолько я опытен, видимо. "Вчера я установил новую библиотеку и с помощью неё PostgreSQL заработал в два раза быстрее! Скорее садитесь, я расскажу вам как устанавливать библиотеки".
Да, много кликбейта в статьях, которые оказываются заурядными. Но, простите, вы все статьи в блоге этой компании читали? Вот прямо каждый раз - вижу OTUS, морщусь, но покупаюсь на громкий заголовок. В результате - действительно полная вода, но в конце "кстати, у нас снова новый курс по какой-то фигне".
Так и что, стал постгрес в 2 раза быстрее? Или 7 лет назад всё забросили, а сегодня откопали из могилы ради пары халявных просмотров?
Фу такими быть
Как я понимаю, обмен через общую память между приложениями доступен только при запуске на одном устройстве. Нет сетевой "прозрачности".
Ядро операционной системы тоже модернизируется, возможно, за эти 7 лет обмен через стандартные сокеты на localhost тоже стал более производительным. Нужно тестировать.
Вроде такой подход используется в любительских портах Android игр на PS Vita)
Как понял загружается родной андрюшный .so, далее перехватываются проблемные функции и просто патчатся при запуске
Уже неделю пытаюсь разобраться как бы это попробовать провернуть, но видать знаний чёт маловато
ssize_t read(int fd, void *data, size_t size) {
strcpy(data, "I love cats");
return 12;Делать нельзя, никогда, ни при каких обстоятельствах. Мы не знаем размер выделенного массива, по указателю
data. И нам передаётся объём данных, которые запрашивает пользователь size. Надо хотя бы проверять, что 12 символов будет точно больше, чем size. Иначе возможны всякие неприятности, проверка мелкая, но спасает много сил.Пишу, потому что встречал такие косяки в китайских ядрах Android и они приводили к очень тяжёлым трудно уловимым последствиям. Ядро может даже не кернел паникнёт, но будет работать уже страннее.
Допустим, вы успешно заменили системный вызов write
Вы заменили не "системный вызов", вы подменили библиотечный символ (функцию read в данном случае).
Это вообще ни в коем случае не одно и то же.
Системный вызов никуда не делся, он реализован в ядре.
В проекте mptcpd если приложение mptcpwrap, которое с помощью аналогичного трюка превращает обычные сокеты в многопутные.
Трюк с LD_PRELOAD