Рубрика «garbage collector» - 3

в 19:47, , рубрики: garbage collector, ruby, ruby on rails, Программирование, сборка мусора, метки: , , ,

Коити: Порог срабатывания сборщика мусора в Ruby — 8 МБ. Почему используется такое маленькое значение?
Matz: Потому что 20 лет назад я работал на машине с 10 МБ памяти.

Вопрос производительности всегда был одним из наиболее обсуждаемых и актуальных в Ruby-сообществе. Будь то высоконагруженный веб-сайт или простой скрипт по бекапу данных — скорость работы является их важнейшей характеристикой. При этом знание возможностей и ограничений языка разработки зачастую служит важным источником идей для оптимизации, позволяет «выжать» максимум из системы.

В статье речь пойдет об одной из наиболее сильно влияющих на производительность частей языка Ruby — сборщике мусора, алгоритмах его работы и улучшениях, внесенных в его работу в последних версиях языка. Речь пойдет о наиболее распространенной, «канонической» реализации Ruby — так называемой MRI или CRuby.
Читать полностью »

в 15:56, , рубрики: garbage collector, ruby, ruby on rails, unicorn, unicorn-worker-killer

Как оптимизировать процессы Unicorn в Ruby on Rails приложении
Если вы являетесь rails-разработчиком, то вы наверняка слышали про Unicorn, http-сервер, способный одновременно обрабатывать множество запросов.

Для обеспечения параллельности Unicorn использует создание множества процессов. Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.

Это здорово, т.к. нам тяжело быть уверенными, что наш код является потокобезопасным. Если мы не можем быть уверены в этом, то ни о параллельных веб-серверах, таких как Puma, ни даже об альтернативных реализациях Ruby, реализующих параллелизм, таких как JRuby и Rubinius, не может быть и речи.

Поэтому Unicorn предоставляет нашим rails-приложениям параллельность даже если они не потокобезопасны. Однако, это требует определенной платы. Rails-приложения, запускаемые на Unicorn’е требуют гораздо больше памяти. Не обращая никакого внимания на потребление памяти вашим приложением, вы можете в итоге обнаружить, что ваш облачный сервер перегружен.

В этой статье мы рассмотрим несколько способов использования параллельности Unicorn'а, при этом контролируя количество потребляемой памяти.
Читать полностью »

в 10:18, , рубрики: garbage collector, meetup, python, Viber, wargaming.net, Блог компании Wargaming.net, минск, Программирование, метки: , , , , , ,

image

Координаты для любителей пообщаться на около-python-овские темы уже определены: последняя пятница месяца, центр Минска, Python Meetup. И традиционно, до проведения следующего митапа мы публикуем видео предыдущей встречи – в сентябре мы обсуждали Garbage collector: что, зачем, почему?
Читать полностью »

в 8:06, , рубрики: garbage collector, java, Программирование, метки:

image 

Все java-разработчики, рано или поздно, встречаются с пресловутой ошибкой OutOfMemoryError.

После этой встречи мы начинаем более бережно относится к используемой памяти, экономить ее. Начиная с версии 1.2 в Java появился пакет java.lang.ref.* с классами SoftReference, WeakReference, PhantomReference. Далее я расскажу вам о том, как помогут эти классы в борьбе с OutOfMemoryError. И что более интересно, приведу реальные примеры их использования. Начнем. Читать полностью »

в 9:36, , рубрики: cloud computing, cloud hosting, garbage collector, java, Java 6, java 7, jvm, memory leaks, paas, platform as a service, Блог компании Jelastic, платформа как услуга, хостинг, метки: , , , , , , , , ,

Как известно, приложение не всегда использует одинаковое количество ресурсов, но благодаря функции автоматического вертикального масштабирования, в Jelastic изменяется размер контейнера под приложение. Соответственно пользователю не нужно переплачивать за зарезервированные ресурсы, которые не используются, как в случае с другими PaaS. Ведь действительно, бизнес-модель всей хостинговой индустрии и старого поколения PaaS решений основана на «overselling». Таким образом, важность справедливой оплаты за фактическое потребление ресурсов очевидна.

imageПонятное дело, что в то время, когда разрабатывали JVM, никто не знал об облаках или виртуализации, и, тем более, никто даже не задумывался о плотности в PaaS. Сегодня виртуализация изменила ход игры в хостинговой индустрии, и эта революция будет продолжаться. Теперь мы можем более эффективно использовать ресурсы. Майкл Видстендт, один из главных архитекторов JVM в Oracle, подтвердил, что JVM совсем не предназначена для PaaS, но Oracle делает все возможное, чтобы изменить это. Плюс ребята из IBM двигаются в том же направлении. Некоторые примечания о динамическом поведением JVM можно найти в IBM JavaOne Keynote 2012 Highlights.Читать полностью »

в 14:13, , рубрики: garbage collector, java, jvm, высокая производительность

Весь поисковый индекс Google размещается в RAM памяти уже как минимум 5 лет. Почему бы не попробовать сделать то же самое и с поисковым индексом для Lucene?

В последнее время, оперативная память стала весьма недорога, поэтому для высоконагруженных ресурсов, вполне резонно ожидать серьезного улучшения производительности за счет размещения поискового индекса целиком в оперативной памяти.

Очевидный вопрос – не попробовать ли нам загрузить весь индекс, в предоставляемый Lucene класс RAMDirectory?
Читать полностью »

в 15:51, , рубрики: garbage collector, java, jvm, высокая производительность, метки: , ,

Споры о том, что лучше: ручное управление или автоматическое ведутся во многих областях науки и техники. Положиться на человека или отдаться на откуп бесстрастным механизмам и алгоритмам? Похоже, что в мире создания Enterprise решений чаша весов склонилась все-таки в сторону автоматического управления памятью, большей частью из-за того, что возиться с указателями, ручным управлением памятью и закрашивать седину после каждого бага, появившегося из-за «неправильного» компилятора С/C++ не хочется сейчас уже никому. Но до сих пор возникают на форумах топики, где не сдающиеся суровые приверженцы ручного управления памятью яростно и непримиримо отстаивают свои ретроградные взгляды в борьбе с прогрессивной частью человечества. Пусть их, оставим их в покое.

Одной из наиболее часто использующихся платформ с механизмами автоматического управления памятью стала Java. Но, автоматическое управление памятью принесло не только комфорт в нелегкий труд программистов, но и свои недостатки, с которыми приходиться сталкиваться всё чаще и чаще. Современные многопользовательские приложения, способные обработать огромный поток транзакций, требуют значительных аппаратных ресурсов, размеры которых раньше было трудно даже вообразить. Однако, дело не в размерах этих ресурсов, дело в том, что сборщик мусора, существующий в большинстве современных JVM, не может работать эффективно с большими объемами памяти.
Читать полностью »

123
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js