Им это надо аргументированно репортить, иначе ничего не изменится.
Не могу сказать, что они бросаются всё исправлять, но процесс в целом идёт, очевидные патчи они принимают: раз, два, а сложные баги в работу берут: три.
> Теперь нам стало понятно, что высокое потребление памяти — это следствие создания большого количества потоков при работе сервиса.
А разработчикам об этом сообщали?
Наверняка ведь вы не одни, кто использует tcmalloc, значит проблема вполне реальная. Ну и вообще логика работы с «одноразовыми» потокам — прямо скажем, посредственная, непонятно зачем так делать.
package в proto нужен не только и не столько для неймспейсов в PHP — с точки зрения protobuf все proto находятся в одном, глобальном нейспейсе. Поэтому мессадж MyMessage{} из pds2.proto будет пересекаться с методом MyMessage{} из totally_different.proto, если у них не прописаны / совпадают package.
Это (на мой взгляд) вообще не очевидно, т.к. и сервис, и клиент после генерации прекрасно работают, но когда нужно подключить второй proto — бабах! Возможно, вы даже получите об этом ошибку, но это не точно.
Вообще, gRPC и protobuf в PHP, как мне кажется, писал какой-то штрафбат, т.е. сотрудники, которых реально наказали за что-то, поэтому там качество соответствующего уровня:
Например, поддержка proto2 там была просто закомментирована if (proto == «proto2») {ошибка}. Или вот тикет — сломали uint32 на x84-64. Или вот — дедлок внутри gRPC потому что никто не проверяет результаты функций.
Но самый мой любимый кейс такой — в модуль gRPC пришлось специально добавлять (довольно костыльно) поддержку fork(). Авторы сказали, что они не расчитывали на то, что этот код будет использоваться в языках, где есть fork(). Код при этом написан на Си (facepalm.jpg).
В общем, мы всё ещё собираем грабли, которые сотрудники Google заботливо разбросали по всему коду grpc и protobuf. Надеюсь, они уже подходят к концу.
я б на вашем месте смотрел в сторону решения, которое предусматривает отсутствие NFS. мы выпилили NFS вообще везде примерно лет так 8 назад и ничуть не жалеем. сейчас сетевых FS и хранилищ разных много, слава богу.
Честно говоря, мы не используем это в Badoo — все узкие места в бизнес-логике, а не в обработке сетевых соединений, поэтому нам (пока?) вполне хватает libevent.
А пост — перевод.
Думаю, этот вопрос лучше задать тому же Линусу или Эндрю Мортону. Судя по гит-репозиторию, AIO в ядре достаточно давно и многие патчи после 2005 года (т.е. после перехода на Git) были signed-off самим Линусом или Мортоном.
На мой взгляд, это нормальная ситуация в больших opensource-проектах — да, есть части кода, которые не очень нравятся основателю. Тем не менее, они удовлетворяют нужды пользователей, не ломают другие части проекта и работают так, как задумано.
Нет, PHP 7.1 пока тестируется.
Задача не супер-приоритетная, т.к. мы не ожидаем двухкратного прироста производительности, поэтому переход планируется где-то в течение месяца.
Артём немного перепутал, у нас в модуле для NGINX для операций с изображениями используется Intel Performance Primitives, а не Leptonica. У IPP сравнительно более сложный API, но она объективно работает быстрее той же лептоники, которую мы используем для аналогичных операций с изображениями в PHP.
Насколько быстрее — точно не помню, но процентов 25 было, если я не ошибаюсь.
Ранее у нас для всех операций с изображениями в PHP использовался ImageMagick. У него есть несколько безусловных плюсов: он тотально всеяден, там хорошая реализация bicubic interpolation, которая в итоге даёт очень приятный результат при ресайзе фотографий. Кроме того, ImageMagick — это такой Фотошоп под Линукс, там есть всё, что можно. Но у него есть один серьёзный минус — он ну очень медленный.
Изначально нам нужно было решить проблему — ресайз фото медленный. На тот момент (примерно 7 лет назад), Лептоника точно так же не очень была известна =), но с задачей ресайза справлялась примерно в два раза быстрее.
В процессе, как всегда, задача немного разрослась и теперь там не только ресайз, но и разнообразные операции над изображениями, но в Лептоника написана на понятном plain C и её патчить гораздо проще и приятнее, чем ImageMagick. Сейчас, возможно, есть какие-то другие библиотеки с аналогичным функционалом, но переходить на них будет уже сложнее из-за всяких кастомных вещей, которые мы добавили в Лептонику. В основном это функционал для генерации капчи, которая у нас выглядит примерно так:
А вообще, это всё дебаг по телефону. Мне надо видеть, иметь возможность запустить это всё.
Ну, и совсем неясно почему это всё обсуждается в этом топике =)
Во-первых, очевидно, что никому это не надо настолько сильно, чтоб взяться за разработку.
Во-вторых, почему вы решили, что это какая-то серебряная пуля?
В Zend заимплементили JIT, поэкспериментировали и убрали пока в сторону: http://marc.info/?l=php-internals&m=142503908926686
TL;DR: первое выполнение скрипта — вплоть до нескольких минут, второе — выигрыша особого не даёт.
Скриншот лога не очень помогает. Как минимум, нужен backtrace.
Как его получить — написано тут: https://bugs.php.net/bugs-generating-backtrace.php
Я понимаю, что у вас времени нет, но если просто жаловаться на Хабре, то ничего не изменится.
FastCGI — это протокол. Не совсем понятно причём тут stateful/stateless реализации движка.
Конкретно такого поведения никогда не будет, я уверен.
Как минимум потому, что уже есть методы, которые позволяют добиться такого же результата без переписывания всего с нуля. Просто храните это значение где-то. В той же shared memory, например.
Не могу сказать, что они бросаются всё исправлять, но процесс в целом идёт, очевидные патчи они принимают: раз, два, а сложные баги в работу берут: три.
А разработчикам об этом сообщали?
Наверняка ведь вы не одни, кто использует tcmalloc, значит проблема вполне реальная. Ну и вообще логика работы с «одноразовыми» потокам — прямо скажем, посредственная, непонятно зачем так делать.
Новый — это jemalloc? Если нет, то пробовали ли его?
Это (на мой взгляд) вообще не очевидно, т.к. и сервис, и клиент после генерации прекрасно работают, но когда нужно подключить второй proto — бабах! Возможно, вы даже получите об этом ошибку, но это не точно.
Вообще, gRPC и protobuf в PHP, как мне кажется, писал какой-то штрафбат, т.е. сотрудники, которых реально наказали за что-то, поэтому там качество соответствующего уровня:
Например, поддержка proto2 там была просто закомментирована if (proto == «proto2») {ошибка}. Или вот тикет — сломали uint32 на x84-64. Или вот — дедлок внутри gRPC потому что никто не проверяет результаты функций.
Но самый мой любимый кейс такой — в модуль gRPC пришлось специально добавлять (довольно костыльно) поддержку fork(). Авторы сказали, что они не расчитывали на то, что этот код будет использоваться в языках, где есть fork(). Код при этом написан на Си (facepalm.jpg).
В общем, мы всё ещё собираем грабли, которые сотрудники Google заботливо разбросали по всему коду grpc и protobuf. Надеюсь, они уже подходят к концу.
А пост — перевод.
На мой взгляд, это нормальная ситуация в больших opensource-проектах — да, есть части кода, которые не очень нравятся основателю. Тем не менее, они удовлетворяют нужды пользователей, не ломают другие части проекта и работают так, как задумано.
Задача не супер-приоритетная, т.к. мы не ожидаем двухкратного прироста производительности, поэтому переход планируется где-то в течение месяца.
Насколько быстрее — точно не помню, но процентов 25 было, если я не ошибаюсь.
Ранее у нас для всех операций с изображениями в PHP использовался ImageMagick. У него есть несколько безусловных плюсов: он тотально всеяден, там хорошая реализация bicubic interpolation, которая в итоге даёт очень приятный результат при ресайзе фотографий. Кроме того, ImageMagick — это такой Фотошоп под Линукс, там есть всё, что можно. Но у него есть один серьёзный минус — он ну очень медленный.
Изначально нам нужно было решить проблему — ресайз фото медленный. На тот момент (примерно 7 лет назад), Лептоника точно так же не очень была известна =), но с задачей ресайза справлялась примерно в два раза быстрее.
В процессе, как всегда, задача немного разрослась и теперь там не только ресайз, но и разнообразные операции над изображениями, но в Лептоника написана на понятном plain C и её патчить гораздо проще и приятнее, чем ImageMagick. Сейчас, возможно, есть какие-то другие библиотеки с аналогичным функционалом, но переходить на них будет уже сложнее из-за всяких кастомных вещей, которые мы добавили в Лептонику. В основном это функционал для генерации капчи, которая у нас выглядит примерно так:
https://gist.github.com/391f7728dddeecc8cc34
А вообще, это всё дебаг по телефону. Мне надо видеть, иметь возможность запустить это всё.
Ну, и совсем неясно почему это всё обсуждается в этом топике =)
Не пробовали его?
Ждать или делать — ваш выбор.
Во-вторых, почему вы решили, что это какая-то серебряная пуля?
В Zend заимплементили JIT, поэкспериментировали и убрали пока в сторону:
http://marc.info/?l=php-internals&m=142503908926686
TL;DR: первое выполнение скрипта — вплоть до нескольких минут, второе — выигрыша особого не даёт.
Как его получить — написано тут: https://bugs.php.net/bugs-generating-backtrace.php
Я понимаю, что у вас времени нет, но если просто жаловаться на Хабре, то ничего не изменится.
Конкретно такого поведения никогда не будет, я уверен.
Как минимум потому, что уже есть методы, которые позволяют добиться такого же результата без переписывания всего с нуля. Просто храните это значение где-то. В той же shared memory, например.
Вам каких не хватает?