Столкнулся я недавно с небольшой проблемой: данные из сессии рандомно пропадали при простое сессии больше 24 (как выяснилось позже) минут.

Вот, что рассказал мне мануал:

Просроченные сессии на самом деле не подвергаются уничтожению сразу же по истечении 24 минут. Вот как все происходит: в начале каждого запроса, использующего сессию (вследствие предварительного вызова функции session_start( ) или установки session/auto_start в on), существует 1% возможности того, что PHP-интерпретатор отсканирует все сессии на сервере и удалит любую из просроченных. «1% возможности» в отношении компьютерной программы звучит совершенно непредсказуемо. Так оно и есть. Но подобная непредсказуемость повышает общую производительность. Интенсивно работающий сайт, занятый в начале исполнения каждого запроса поиском просроченных сессий в целях их удаления, станет расходовать слишком много ресурсов сервера.

Это объясняет «рандомность» удаляемых данных.
Но как решить эту проблему, поскольку в моем проекте время простоя запросто может быть больше 24 минут.

Речь пойдёт о сборке мусора и утечках памяти в разных браузерах.

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

В данном топике речь пойдет о причинах, вызывающих длинные паузы сборщика мусора и о способах борьбы с ними. Рассказывать я буду о CMS (low pause), так как на данный момент это наиболее часто используемый алгоритм для приложений с большой памятью и требованием малой задержки (low latency). Описание дается в предположении, что у вас приложение крутится на боксе с большим объемом памяти и большим количеством процессоров.

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

История 1

Собственно, началось все с того, что пришел баг о том что при некоторых операциях приложение вылетает. Это бывает часто. Баг не захотел воспроизводиться в Debug-версии. Это порой бывает. Поскольку в приложении часть библиотек была написано на C++, то первой мыслью было что-то вроде «где-то забыли переменную проинициализировать или что-то в этом духе». Но на деле суть бага крылась в управляемом коде, хотя без неуправляемого тоже не обошлось.

Во время написания статьи про использование фантомных ссылок, мне потребовалось сослаться на неудобства возникающие при работе с методом finalize. К тому же, считаю, что данный топик будет полезен всем начинающим java разработчикам, а некоторые пункты будет не лишним вспомнить и матерым программистам, ведь использовать метод finalize очень просто, чего не скажешь о поиске последсвий этого. Даже если вы твердо убеждены никогда не использовать метод finalize, это еще не значит, что ваши предыдущие коллеги их не использовали, и вам не надо понимать как они работают.

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

Подкаст

Rpod

Новости

Errbit — opensource error catcher совместимый с Airbrake API
Ruby style guide
Jbuilder от DHH
GC in Ruby 2.0
Документация по Rails, Ruby-core и Ruby stdlib
Валидация на грани фола — статья на харбре про валидацию
23 марта вышел Factory Girl 3.0
17 марта вышел Rspec 2.9.0

На недавно прошедшей Java One Руслан cheremin рассказывал о том, что разработчики Disruptor используют JVM без сборщика мусора. У них на то были свои причины, которые не имеют к этому топику никакого отношения.

Я же давно хотел поковыряться в исходниках виртуальной машины, и выпиливание из неё GC – отличное начало. Под катом я расскажу вам, как собрать OpenJDK, выпилить из неё сборщик мусора и снова собрать. Ближе к концу даже будет дан ответ на наверняка пришедший вам в голову вопрос «зачем».

Сегодня немного поэкспериментируем с методом finalize() и уничтожением объектов. Хотя даже начинающие Java-программисты примерно представляют, что finalize() вызывается, когда сборщик мусора решит уничтожить ваш объект, некоторые вещи могут всё-таки оказаться неожиданными. К примеру, зададимся вопросом: что случится с вашим приложением, если метод finalize() работает очень долго?

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

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

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

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

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

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

Считается, что сборщик мусора – черный ящик, работу которого нельзя предугадать.

А еще говорят, что GC в .NET практически не настраиваемый. А еще, что нельзя посмотреть исходники как классов .NET Framework, так и CLR, GC и т.п.

А я скажу как бы ни так!

В данной статье мы рассмотрим:

• структура организации размещения объектов в памяти
• CLR 4.5 Background Server GC
• правильная настройка сборщика мусора
• эффективный апгрейд приложений до .NET 4.0+
• правильное ручное управление памятью

Подкаст

http://ruby.rpod.ru/282270.html

Новости

• Стриминг в новой рельсе
• mortal-token
• travis-api
• Ransak
• Metaprogramming in Ruby
• BinUtils from funny-falcon
• bit.ly on Ruby
• Yet another JSON parser and discussion on reddit
• SublimeText package for generating Yardoc
• Narihiro Nakamura: Ruby’s GC Innovator
• Unexpected Ruby Behaviour
• Ruboto 0.8.0

Данная статья призвана систематезировать знания о всех современных сборщиках мусора, используемых в HotSpot, JRockit и J9 JVMs. Статья содержит краткий обзор всех режимов сборки мусора с проведенными аналогиями между всеми рассматриваемыми здесь JVM. Статья будет интересна всем, кто интересуется вопросом GC, а также будет полезна тем, кто рассматривает или планирует совершать портирование JAVA приложений на альтернативные JVM.

Все знают о том, что для повышения эффективности сборки мусора большинство современных систем используют поколения. Но вы когда-нибудь задумывались о том, как вообще эти поколения работают, и за счет чего мы получаем выигрыш в производительности? Но давайте не будем забегать вперед и разберем все по порядку.

Итак, большинство современных систем сборки мусора (Garbage Collector, GC) используют поколения для более эффективного освобождения короткоживущих объектов. Существует эвристическое правило, которое говорит о том, что большая часть вновь созданных объектов используются очень короткое время и их спокойно можно будет удалить при первой же возможности.

В этом посте будут рассмотрены пять путей повышения эффективности кода, помогающие сборщику мусора проводить меньше времени за выделением и освобождением памяти. Долгая процедура сборки мусора может привести к явлению, известному как «Stop the world».

Общие сведения

Сборщик мусора (Garbage Collector, GC) существует для обработки большого количества выделений памяти под короткоживущие объекты (например, объекты выделенные в процессе рендеринга веб-страницы, устаревают сразу как только страница показана).

GC в этом случае использует так называемое «молодое поколение» («young generation») — сегмент кучи, где размещаются новые объекты. Каждый объект имеет поле «возраст» («age», находится в заголовке объекта), который определяет сколько сборок мусора он пережил. Как только достигнут определенный возраст, объект копируется в другую область кучи, называемую «старым» («old») поколением.

Процесс все еще эффективен, но уже становится заметен. Способность уменьшить количество выделений памяти под временные объекты, поможет нам увеличить производительность, особенно в широко масштабированных окружениях или в Android-приложениях, где ресурсы более ограничены.

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

И снова привет, хабраюзер!

Это вторая статья, посвященная тестированию сервера Skyforge. На всякий случай напоминаю, что Skyforge – это MMORPG, сервер которой рассчитан на сотни тысяч игроков и написан на Java.
В отличие от первой части, где речь идет о роли ботов, эта статья рассказывает о нагрузочном тестировании и метриках.

В последнюю пятницу октября в Минске традиционно прошел Python Meetup, на котором вприкуску с бургерами были зачитаны три доклада от спецов из компаний Viber, Melesta и Wargaming.net. На этот раз прошлись по недостаткам Python, разобрались на примере, с какими проблемами можно столкнуться при портировании на Python, а также рассмотрели все этапы разработки серверов на Python для социальных игр. Все видео, а также ссылки на презентации можно найти чуть ниже.

15 октября славный город Санкт-Петербург посетил суперзлодей Вселенной Joker.
Нет, он никого не убил, и ни один Бэтмен не пострадал. Но его посещение, тем не менее, запомнится многим. Во-первых, это была премьера новой конференции по Java технологиям. Во-вторых, эта конференция удалась на славу, а значит, её ждёт большое будущее, а первая конференция – всегда история.

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

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

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