Патч 1.9.3-p0

[funny_falcon]

https://gist.github.com/1658360 - сборный патч, ускоряющий загрузку и общую производительност (ускоряет создание хешей и уменьшает потребяемую при этом память)

Тем, кто работает на Windows, будет также интересно https://github.com/thecodeshop/ruby/wiki/Downloads

[Max Lapshin]

А чего именно ты там делаешь?

1) кеширование load path
2) организация чего-то в пулы
3) memalign этих пулов

так?

[funny_falcon]

1) кеширование "expanded load path" - "раскрытие" путей загрузки - основное ускорение при запуске приложения.

  Без патча это практически неизбежно происходит каждый раз при вызове "require" (т.е. несколько десятков путей проходят через File.expand_path).
  С патчем это происходит очень редко.

2) сортировка loaded features - ещё +6% при запуске.

  При вызове require каждый раз происходит поиск требуемого файла среди уже загруженных.
  Без патча применяется простой линейный поиск. С патчем - практически бинарный поиск.

3) ускорение создания хешей и уменьшение потребления памяти при этом.
  Во время работы rails приложения большая часть вызовов выделения памяти происходит именно из-за создания хэшей.
  По-этому имеет смысл ещё ускорить :)

  a) упаковка маленьких хешей

  Без патча хэш занимает 24 байта на st_table, минимум 44 байта на bins и по 24 байта на каждый элемент хэша.
  С патчем хэши размера 0 и 1 умещаются в st_table. Хеши от 2 до 6 элементов требуют ещё 72 байта, что в сумме (24+72=96) меньше чем хеш с двумя элементами без патча (24 + 44 + 24*2 = 116), ну и значительно меньше, чем хэш с шестью елементами (212 байт).
  Кроме того, оказалось, что поиск в таком упакованном хэше (простой перебор в массиве) быстрее, чем в не упакованном как раз до размера в 6 элементов. Видимо это связано с тем, что произвольный доступ к памяти (промах мимо кэша) дороже, чем пять-шесть сравнений.
  В ruby без патча эта техника применена во внутренних хэшах. Этот патч распространяет её и на хэши, доступные из приложения.

  b) внутренний аллокатор для st_table, st_table_element и bins наименьшего размера.
 
  Аллокаторы памяти неизбежно перегружены: проверкой правильности освобождения памяти, синхронизацией между потоками и прочим.
  Будучи уверенным в алгоритме st_table, и зная, что синхронизацию обеспечивает GIL, можно дать ему в руки максимально простой аллокатор. Что, собственно, патч и делает.
  Выделяются пулы примерно по 8Кбайт, в каждом создаётся linked list, и выделение-освобождение памяти в большинстве случае занимает пару сравнений и пару присваиваний указателю.
  При этом улучшается и потребление памяти, т.к., этот аллокатор имеет очень маленькие дополнительные затраты памяти, а сотрудничество со сборкой мусора руби позволяет ему избегать большой фрагментации.

  Интересно, что для структур большего размера особого выигрыша получить не удалось. Я даже отказался от такого выделения памяти для упакованного хэша (72 байта).
 

[Dmitry A. Ustalov]

Выглядит задорно, вечером попробую обкатать. Есть ли уже success
stories? :)

[Akzhan Abdulin]

Никто не дожил до рассылки

25 января 2012 г. 10:03 пользователь Dmitry A. Ustalov <dmi...@eveel.ru> написал:

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ

 Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror...@googlegroups.com
 Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-un...@googlegroups.com
 Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru

[funny_falcon]

https://gist.github.com/1658360#gistcomment-77804
https://gist.github.com/1658360#gistcomment-77859

Данных тестирования нагрузки сервер серверов пока нет. Локально на redmine вижу ускорение на несколько процентов. Если используется tcmalloc, ускорение скромнее, но тоже имеется.
Ускорение будет тем больше, чем больше используются хелперы с параметрами - т.е. когда создаётся туча маленьких хешей.

[funny_falcon]

Патч включён в состав rvm:

rvm get head
rvm install 1.9.3 -n falcon --patch falcon -j 3

https://gist.github.com/1688857#gistcomment-79311
https://github.com/wayneeseguin/rvm/commit/828283dfda64d36cea41ac5f603ff348036426b1

[Zabazhanov Arkady]

Безумно крутая работа проделана, спасибо. Кстати, а почему вэйн не включает https://github.com/skaes/rvm-patchsets в rvm? По-моему, раз уж rvm позволяет - надо все патчи там собирать.

29 января 2012 г. 13:20 пользователь funny_falcon <funny....@gmail.com> написал:

[Dmitry A. Ustalov]

Ты очень крутой.

> https://gist.github.com/1688857#gistcomment-79311https://github.com/wayneeseguin/rvm/commit/828283dfda64d36cea41ac5f60...

[Oleksiy Kovyrin]

$ rvm install 1.9.3 -n falcon --patch falcon
Fetching yaml-0.1.4.tar.gz to /Users/me/.rvm/archives
Extracting yaml-0.1.4.tar.gz to /Users/me/.rvm/src
Configuring yaml in /Users/me/.rvm/src/yaml-0.1.4.
Compiling yaml in /Users/me/.rvm/src/yaml-0.1.4.
Installing yaml to /Users/me/.rvm/usr
Installing Ruby from source to:
/Users/me/.rvm/rubies/ruby-1.9.3-p0-falcon, this may take a while
depending on your cpu(s)...

ruby-1.9.3-p0-falcon - #fetching
ruby-1.9.3-p0-falcon - #extracted to
/Users/me/.rvm/src/ruby-1.9.3-p0-falcon (already extracted)
Applying patch 'falcon' (located at
/Users/me/.rvm/patches/ruby/1.9.3/p0/falcon.patch)
Error running 'patch -F 25 -p1 -N -f
<"/Users/me/.rvm/patches/ruby/1.9.3/p0/falcon.patch"', please read
/Users/me/.rvm/log/ruby-1.9.3-p0-falcon/patch.apply.falcon.log

В логе - очень грязно накладывается патч c кучей Hunk #X FAILED at XXX.

2012/1/29 funny_falcon <funny....@gmail.com>:

> --
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы
> "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
> Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror...@googlegroups.com
> Чтобы отменить подписку на эту группу, отправьте сообщение по адресу:
> ror2ru-un...@googlegroups.com
> Дополнительные варианты находятся на странице группы
> http://groups.google.com/group/ror2ru?hl=ru

--
Oleksiy Kovyrin
http://kovyrin.net/

[funny_falcon]

> /Users/me/.rvm/src/ruby-1.9.3-p0-falcon (already extracted)

> В логе - очень грязно накладывается патч c кучей Hunk #X FAILED at XXX.

Ты не удалил предыдущую установку, вот патч повторно и накладывается.

[Maxim Filatov]

On Jan 29, 2012, at 6:28 PM, Oleksiy Kovyrin wrote:

В логе - очень грязно накладывается патч c кучей Hunk #X FAILED at XXX.

$ rvm cleanup sources

--

Best regards,

Maxim Filatov

[Mikhail Lapshin]

Действительно, очень круто.

2012/1/22 funny_falcon <funny....@gmail.com>:

[Andrey Voronkov]

https://twitter.com/#!/tenderlove/status/164791981552320514 - таки вы становитесь популярны!

29 января 2012 г. 22:22 пользователь Mikhail Lapshin <sota...@sotakone.com> написал:

[funny_falcon]

Сам в шоке. Никогда не вёл twitter, и вообще блога нет... Думаю теперь, что же туда писать.

[Alex Dmitriev]

Новые патчи пиши ;)

3 февраля 2012 г. 10:38 пользователь funny_falcon
<funny....@gmail.com> написал:

> Сам в шоке. Никогда не вёл twitter, и вообще блога нет... Думаю теперь, что
> же туда писать.
>

> --
> --
> Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы
> "RubyOnRails to russian" на группах Google.
> FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
>
> Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
> ror...@googlegroups.com
> Чтобы отменить подписку на эту группу, отправьте сообщение по адресу:
> ror2ru-un...@googlegroups.com
> Дополнительные варианты находятся на странице группы
> http://groups.google.com/group/ror2ru?hl=ru

--
Alex V. Dmitriev
Jabber/GTalk/MSN/AIM: rene....@gmail.com
Skype: rene-dekart
Blog: http://railorz.ru

[Oleksiy Kovyrin]

2012/2/3 funny_falcon <funny....@gmail.com>:

> Сам в шоке. Никогда не вёл twitter, и вообще блога нет... Думаю теперь, что
> же туда писать.

Главное не начинай писать вещи типа "ой, проснулся", "ух ты, сходил в
сортир!" :-)

[Oleksiy Kovyrin]

+100

2012/2/3 Alex Dmitriev <rene....@gmail.com>:

--
Oleksiy Kovyrin
http://kovyrin.net/

[Andrey Voronkov]

Даа - как раз Aaron Patterson такими вещами страдает.

3 февраля 2012 г. 17:46 пользователь Oleksiy Kovyrin <ale...@kovyrin.net> написал:

[Alexey Bondar]

On 3 Feb 2012, at 17:58, Andrey Voronkov wrote:

> Даа - как раз Aaron Patterson такими вещами страдает.

Вы что-то имеете против домашних сосисок?!

[Timothy N. Tsvetkov]

шабат шалом чят.

2012/2/3 Alexey Bondar <alexey...@gmail.com>

On 3 Feb 2012, at 17:58, Andrey Voronkov wrote:

> Даа - как раз Aaron Patterson такими вещами страдает.

Вы что-то имеете против домашних сосисок?!

[codesnik]

подниму-ка тредик.

используем патч в продакшне уже месяц.

работает, вот только за неделю набегает два-три инстанса, отъедающих ядро на 100%, и реагирующих только на kill -9.

При нашей нагрузке уже можно утверждать, что это достаточно редкое событие, но все же.

грешил на C-экстеншны, но недавно встрял кронтаск, в котором ни xml-парсеры, ни обертки curb не используются. В общем, скорее всего, не оно.

пробовал подцепиться к процессам с помощью hijack. https://github.com/ileitch/hijack

hijack утверждает, что с трех попыток не смог попасть между GC-runs.

В общем, там перманентный GC, подцепился gdb без оберток, первые шестьсот строк бэктрейса - внутри gc.c.

завтра-послезавтра переключу продакшн на ванильный 1.9.3, посмотрим, будет ли повторяться, но похоже, дело все-таки в патче.

на один зависший инстанс послал SIGSTOP, могу проинспектировать, если скажете, что именно.

[funny_falcon]

воскресенье, 18 марта 2012 г. 4:20:05 UTC+4 пользователь codesnik написал:

подниму-ка тредик.

используем патч в продакшне уже месяц.

работает, вот только за неделю набегает два-три инстанса, отъедающих ядро на 100%, и реагирующих только на kill -9.

При нашей нагрузке уже можно утверждать, что это достаточно редкое событие, но все же.

грешил на C-экстеншны, но недавно встрял кронтаск, в котором ни xml-парсеры, ни обертки curb не используются. В общем, скорее всего, не оно.

пробовал подцепиться к процессам с помощью hijack. https://github.com/ileitch/hijack

hijack утверждает, что с трех попыток не смог попасть между GC-runs.

В общем, там перманентный GC, подцепился gdb без оберток, первые шестьсот строк бэктрейса - внутри gc.c.

завтра-послезавтра переключу продакшн на ванильный 1.9.3, посмотрим, будет ли повторяться, но похоже, дело все-таки в патче.

на один зависший инстанс послал SIGSTOP, могу проинспектировать, если скажете, что именно.

 

Добрый день.

Можете попробовать патч для более поздней версии, чем p0?

https://gist.github.com/1859082

Также он доступен в rvm --patch falcon .

Моя почта funny.falcon(на)gmail.com, мой скайп funny.falcon постучись с подпиской "patch ruby"

Как понимаю, этот процесс висит остановленный? было бы интересно его вместе подёргать.

Если не получится, то пришли бэктрейс на почту

С уважением,

Юра