Golang runtime

       Не так давно в ходе выкладки в прод memory/cpu лимитов для компонентов наткнулся на интересную особенность поведения Golang runtime. При нехватки CPU ресурсов у приложения написанного на Golang может резко возрастать потребление памяти. Связано это с тем что при увеличении  нагрузки доля CPU выделяемая на сборку мусора уменьшается и в какой-то момент времени мусор начинает генерироваться быстрее чем идет его сборка. 

         В таком режиме go приложение начинает довольно быстро расходовать память и быстро  пристреливается OOM killer-ом. Потом оно перезапускается, но уже с пустыми кэшами. Так как кэши пустые, приложение начинает расходовать еще больше CPU и вероятность того что оно сново уйдет в крутое пике - крайне велика. 

          Первоначальное предположение было - что Go runtime не видит memory limit-ов установленных cgroup. По после чтения исходников я выяснил что go runtime и не пытается увидеть эти лимиты. Действительно, у приложения запущенного без root привилегий не так много возможностей увидеть с какими ограничениями по памяти оно запущено. И даже если у тебя есть root права - эти ограничения будут зависеть от очень многих факторов, и эти факторы будут различаться на каждой поддерживаемой платформе. В общем go runtime просто аллоцирует новые куски памяти до тех пор пока его не прикончит OOM killer или до тех пор пока  операционная система не вернет ему ошибку при очередном вызове mmap(2). В этом случае go runtime падает с паникой.

Nice Go packages

 https://github.com/facebookgo  a lot of small and clean Go packages by guys from parse.com. Every package is really good example of "ideal Go package"

Gocraft gorelic

        Таки да, я снова родил middleware для своего детища - gorelic. Что называется, продвигаю как могу :-)
      https://github.com/yvasiyarov/gocraft_gorelic

Martini Gorelic

     По просьбам трудящихся написал middleware для интеграции Martini framework и NewRelic:
https://github.com/yvasiyarov/martini_gorelic
Пожелания, улучшения, pull requests - are welcome :-)

NewRelic middleware for beego

   Потратил вечер чтобы облегчить жизнь пользователям beego framework.  Теперь подключить NewRelic к любому beego приложению можно за 5 минут:
         https://github.com/yvasiyarov/beego_gorelic
Надеюсь кому-нибуть да пригодится :-)

Go web frameworks

      В последнее время появилось много довольно симпатичных веб фраймворков для Go.  Сегодня решил потыкать несколько из них. Ну и сделать небольшой бенчмарк как водится в таких случаях.  

          Все фраймворки тестировались на одном и том же железе - полудохлом макбуке бородатых годов и компилировались с помощью go1.2.1 darwin/amd64. Дабы избежать холиваров сразу скажу:

• Да, я знаю что бенчмарки Hello word и реального приложения имеют мало общего и я не собираюсь их сравнивать между собой
• Ежу понятно что приложение на чистом net/http будет быстрее. Цель данного исследования - узнать ту "цену" которую нам приходится платить за удобство использования того или иного фраймворка.    

Для тестирования мы используем siege (конкретно siege -c 100 -b -r 100 ). 

И так, Hello world на чистом net/http (исходники доступны на тут ):

 
Transactions:         10000 hits
Availability:        100.00 %
Elapsed time:          4.62 secs
Data transferred:         0.10 MB
Response time:          0.04 secs
Transaction rate:      2164.50 trans/sec
Throughput:          0.02 MB/sec
Concurrency:         77.89
Successful transactions:       10000
Failed transactions:            0
Longest transaction:         0.14
Shortest transaction:         0.00

      Hello world используюя Martini фраймворк (исходники):

 Transactions:              10000 hits  
 Availability:             100.00 %  
 Elapsed time:              6.87 secs  
 Data transferred:         0.11 MB  
 Response time:              0.06 secs  
 Transaction rate:        1455.60 trans/sec  
 Throughput:              0.02 MB/sec  
 Concurrency:              94.52  
 Successful transactions:    10000  
 Failed transactions:           0  
 Longest transaction:         0.42  
 Shortest transaction:         0.00  

Эти результаты наглядно показывают что за все нужно платить. Даже даже не самый сложный фраймворк отъедает значительное количество ресурсов.

           Следующий подопытный - gocraft. По предоставляемым возможностям он очень похож на martini, скажем так - это фремворки одного уровня. Вот результаты тестов gocraft:

 Transactions:              10000 hits  
 Availability:             100.00 %  
 Elapsed time:              4.71 secs  
 Data transferred:         0.10 MB  
 Response time:              0.04 secs  
 Transaction rate:        2123.14 trans/sec  
 Throughput:              0.02 MB/sec  
 Concurrency:              78.24  
 Successful transactions:    10000  
 Failed transactions:           0  
 Longest transaction:         0.33  
 Shortest transaction:         0.00  

Исходники можно посмтреть тут. Я специально не стал убирать middleware's чтобы тесты между gocraft и martini были максимально честными.  Как вы видите показатели практически идентичны чистому net/http. И значительно быстрее martini. Хотя влияние Martini четко просматривается.

        Следующим подопытным будет revel. По предоставляемым возможностям это фреймворк совсем другого уровня, и сравнивать его с предыдущими кандидатами будет не совсем корректно.  Это видно даже по "hello word". Если у martini и gocraft это просто 10 строк исходного кода, то для revel - это целое приложение с MVC структурой и кучей всяких файлов.  Одно хорошо - все эти файлы генерируются автоматически и мы с помощью одной команды: revel new myapp  получаем готовое приложение. А теперь результаты:

 Transactions:              9872 hits  
 Availability:              98.72 %  
 Elapsed time:              34.14 secs  
 Data transferred:         19.24 MB  
 Response time:              0.22 secs  
 Transaction rate:        289.16 trans/sec  
 Throughput:              0.56 MB/sec  
 Concurrency:              64.71  
 Successful transactions:    9872  
 Failed transactions:          128  
 Longest transaction:         20.17  
 Shortest transaction:         0.00  

Сказать что результаты меня разочаровали - значит ничего не сказать. В принципе на PHP +Yii мы получаем тоже самое без всяких оптимизаций. Плюс к тому Availability не 100%... и это у Hello world...  В общем revel меня разочаровал. В консоли он ругался что-то вроде:

 2014/05/11 16:37:22 reverseproxy.go:141: http: proxy error: dial tcp 127.0.0.1:62188: too many open files  
 2014/05/11 16:37:22 reverseproxy.go:141: http: proxy error: dial tcp 127.0.0.1:62188: too many open files  
 2014/05/11 16:37:22 reverseproxy.go:141: http: proxy error: dial tcp 127.0.0.1:62188: too many open files  
 2014/05/11 16:37:22 reverseproxy.go:141: http: proxy error: dial tcp 127.0.0.1:62188: too many open files  
 2014/05/11 16:37:22 reverseproxy.go:141: http: proxy error: dial tcp 127.0.0.1:62188: too many open files  
 2014/05/11 16:37:22 server.go:1633: http: Accept error: accept tcp [::]:9000: too many open files; retrying in 5ms  
 2014/05/11 16:37:22 reverseproxy.go:141: http: proxy error: dial tcp 127.0.0.1:62188: too many open files  

зачем создателю revel понадобился reverse proxy - ума не приложу.
        Последний кандидат на сегодня - beego. По своему уровню он очень похож на revel - он также гененирует целое приложение с кучей папочек. Но результаты у него куда лучше:

 Transactions:              10000 hits  
 Availability:             100.00 %  
 Elapsed time:              20.27 secs  
 Data transferred:         15.19 MB  
 Response time:              0.18 secs  
 Transaction rate:        493.34 trans/sec  
 Throughput:              0.75 MB/sec  
 Concurrency:              90.49  
 Successful transactions:    10000  
 Failed transactions:           0  
 Longest transaction:         0.71  
 Shortest transaction:         0.00  

Response time в 5 раз выше чем у gocraft, но это объяснимо. В общем мой выбор это beego и gocraft. В зависимости от характера приложния.

Go Lang

Вчера нашел одно место в стандартной библиотеке Go( а именно в пакете database/sql), которое можно бы прооптимизировать. Зарепортил им Issue 7086, думал сейчас патч пришлю. Хер там был. Через 2 часа его прокомментировал Дмитрий Вьюков, сегодня с утра Bradfitz уже прислал патч. Оперативно работают ребята, что тут скажешь. Молодцы! В общем решил что перейду на девелоперскую версию - хватит на релизах сидеть.

На почитать

1. Go 1.2 зарелизили! Добавили новый инструмент для проверки покрытия тестами - http://blog.golang.org/cover и еще множество улучшений. Более детально смотрите http://blog.golang.org/go12 
2. http://blog.golang.org/go-at-heroku, оказывается у ZooKeeper есть альтернатива, и написана она на Go. Называется Doozer
3. http://blog.golang.org/building-stathat-with-go - еще на Go написан StatHat. 
4. http://blog.golang.org/from-zero-to-go-launching-on-google - для тех кто не верит что Google использует Go
5. Про то как появился web.go - http://blog.golang.org/real-go-projects-smarttwitter-and-webgo
6. http://blog.golang.org/normalization - нормализация UTF-8 текста в Go.
7. Gopher Academy - большое количество статей (сюрпрайз!) про Go :-) Я буду кидать прямые ссылки на самые интересные по мере прочтения.

На почитать

Как обычно, в основном про Go, но не только:

1. http://www.slideshare.net/alexclear/on-go - обзорная презентация, но много ссылок на различные проекты, написанные на Go
2. https://www.facebook.com/notes/facebook-engineering/the-mature-optimization-handbook/10151784131623920 книга про оптимизацию по взрослому. Надо заставить себя прочитать.
3. http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-decide-to-write-docker-in-go?goback=.gde_3712244_member_5805932917834149890#! - о проекте Docker, и почему именно Go.
4. http://blog.golang.org/4years?goback=.gde_3712244_member_5805932917834149891#! Go 4 года, итоги. Если в общем - все выглядит позитивненько.
5. https://code.google.com/p/go-wiki/wiki/SuccessStories#! Что было сделано на Go.
6. http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=5808846211502845954&gid=3712244&commentID=5809268744651837440&trk=view_disc&fromEmail=&ut=1iTBwgk886fS01 Оказывается Go используют в одном из проектов Rocket'а. В общем зная внутреннюю кухню стартапов Rocket'а могу сказать одно - "респект и уважуха" их CTO. Представляю какое противодействие это встретило со стороны Берлина.  Ведь речь идет не о каком-то инструменте, а об одном из основных веб сервисов.
7.  http://stackoverflow.com/questions/6125683/call-go-functions-from-c - очень хороший пост о том как работать с callback функциями в CGO. Вызов Go функций из процесса, исполняющегося вне Go runtime.
8. http://cheesesun.blogspot.com/2010/04/callbacks-in-cgo.html - еще один пост про CGO и callback функции.
9. http://puppetlabs.com/mcollective - про Puppet. Вообще в последние месяцы я очень плотно занимаюсь Puppet манифестами и невольно сравниваю  Puppet c Solt, который я использовал ранее. В общем сравнение не в пользу Puppet. Я считаю Solt - круче на порядок.    

NSQ - a realtime distributed messaging platform

     Недавно наткнулся на еще один крупный проект написанный на  Go - называется NSQ. Еще одна очередь написанная на Go. Первой подобной системой была  Iron.io, о которой я писал ранее. Основным разработчиком  NSQ является bit.ly, но кроме него эта система используется еще в нескольких крупных проектах. В общем число компаний, использующих Go в продакшене растет, а следовательно растет и рынок Go программистов - что не может не радовать.  

Про Go

     1.  Статья про Go и его использование в Iron.io http://www.businessinsider.com/googles-go-could-replace-java-2013-8
     2.  Оказывается есть очень полезные пакеты, которые также разрабатываются членами Go team, но которые не включены в основное дерево пакетов. Смотрите ссылки на них внизу этой страници http://golang.org/ref/
     3.  Планируется очередная встреча Go сообщества Москвы, со специальным гостем из Go Team - http://goo.gl/V9i0wL

На почитать

      Про  Go:

• Обзор всех нововведений, которые добавляют в development branch Go, за первую половину августа 
• То же самое, но за последнюю неделю

Если в кратце - в Go 1.2 должен появится вытесняющий планировщик задач, улучшена поддержка C++ в cgo, сделаны улучшений в encoder/* пакетах, и много-много других оптимизаций.

     Про Linux:

1. Разработка ядра Linux, by Robert Love (интересная фамилия :-)). Уже есть 3-е издание этой книги, но только в английском варианте.

2. Linux System Programing, того же Robert Love

3. Linux in the Nutshell. Снова Robert Love со товарищами. Плодовитый в общем писака - и вообще много чего другого успел сделать.

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

• про github
• про видео хостинг imgur
• про разработку игр
• про всеми любимый instagram
• еще про игры
• про облака
• про месседжеры
• про блоги
• ну и конечно про твиттер
• про взрослое видео
• про disqus

Solr monitoring in NewRelic

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

      На первом я расположил самые важные характеристики - данные о потреблении памяти самой JVM и о количестве этой самой памяти в системе:

Далее идут данные по количеству запросов в секунду и по среднему времени ответа на каждый из запросов, с разбивкой по типам запросов:

Затем идут данные по обновлению индексов - сколько приходит запросов на обновления и каких они типов:

Также плагин собирает детальную информацию по кэшам, которые использует solr - hitrate для каждого типа кэша и размер этого кэша:

Также имеется детальная разбивка по каждому кэшу - сколько было запросов, сколько промахов, сколько вытеснений и тд:

  Ну и в завершении всего - статистика по ошибкам и таймаутам:

Сам плагин находится вот тут - https://github.com/yvasiyarov/newrelic_solr 

Go best practices

    Очень интересная презентация от Francesc Campoy Flores о том как писать на Go так что и читать потом приятно будет:
      http://talks.golang.org/2013/bestpractices.slide

Go at Google

     Сегодня прочитал классный доклад от Brad Fitzpatrick, про то как они переписали dl.google.com с C++/Python на Go.  Раньше меня спрашивали - вот google создал этот язык, а сами-то они почему его не используют ? Так вот, теперь можно смело заявить: используют и очень успешно - dl.google.com: Powered by Go

          Отдельно хочу сказать про библиотеку groupcache который они использовали для кэширования и получения контента в dl.google.com. Главное ее преимущетво - то что она не только кэширует, но и самостоятельно обновляет кэш -  тем самым решая проблему множественных запросов к backend'у в момент истечения срока годности кэша. Эта библиотка гарантирует что даже в случае множества паралельных запросов к какому-либо ключу, к бэкенду будет выполнено только одно обращение - даже в случае если кэш запущен не на одном сервере а на группе серверов. Так что теперь при разработке Go приложений вопрос кэширования можно считать снятым.  

New Relic Platform Agent SDK for Go(golang)

      Сегодня завершил работу над еще одной библиотекой для языка Go - New Relic Platform Agent SDK.  У самого new relic есть библиотеки только для Java и Ruby. Но и тот и другой не слишком хорошо подходят для написания демонов - так как потребляют немерено памяти. То что не стоило ожидать от них поддержки языка Go - это понятно, но для Python то почему не написали ? Обычный агент для мониторинга Python у них есть, следовательно и программисты пишушие на нем тоже. 

      Go же как нильзя лучше подходит для написания инструментов мониторинга - памяти ест очень мало, с сетью и потоками работать очень легко. В общем с помощью моего SDK можно написать плагин мониторинга за один вечер.

      Надеюсь кому-нибуть будет полезен:

      https://github.com/yvasiyarov/newrelic_platform_go

На почитать

    1. http://code.flickr.net/2013/06/04/adventures-in-jank-busting-parallax-performance-and-the-new-flickr-home-page/ - очень интересная статья про использование аппаратного ускорения при рендеринге веб страницы. Как заставить браузер использовать аппаратное ускорение и какие при этом могут быть подводные камни.  Подробно описано профилирование клиент-сайда, как это делают на flickr.com
    2. http://blog.golang.org/go-and-google-cloud-platform использование Go в Google App Engine
    3. http://www.wired.com/wiredenterprise/2013/06/facebook-hhvm-saga/ - история про то как в Facebook создавали  HipHop Virtual Machine. Очень интересно читать про культуру внутри компании. Думаю в 99% других компаний им бы не дали сделать ничего подобного.
    4. https://www.facebook.com/photo.php?v=432864835468 рассказ от одного из разработчиков HipHop Virtual Machine, Keith Adams - про то как они поиск в Facebook делали.
    5. http://blog.golang.org/a-conversation-with-the-go-team - интервью с людьми работающими над развитием языка  Go. Про то что стоит ждать, и про то чего никогда не будет в языке Go.
    6. http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-go - прекрасное решение для быстрой установки разных версий Go. Для тех кто хочет сравнить насколько ощутимо выросла производительность их кода при переходе с Go 1.0 на Go 1.1
    7. Для тех кто хочет в живую увидеть людей пишущих на Go - сейчас происходит обсуждение предстоящей, уже 3-ей по счету встрече Go- программистов и сочувствующих. Если вы просто интересуетесь этим языком, или просто хотите поделится собственным опытом - приходите, не пожалеете. Обсуждение происходит сдесь: https://groups.google.com/forum/#!topic/golang-ru/6gSeOc76KGQ/discussion

Go ! Go ! Go !

     Сегодня у меня есть очень позитивная новость - еще одна крупная компания начала использование языка Go  в продакшене. Компания 10gen, более известная как разработчик MongoDB объявила о запуске сервиса бэкапов, часть которого написана на Go
     http://blog.labix.org/2013/05/28/gopher-powered-backups 

На почитать

1. Очень хорошая статья про построение архитектуры приложения вообще, и применительно к Go  в частности: http://manuel.kiessling.net/2012/09/28/applying-the-clean-architecture-to-go-applications/

После прочтения статьи у меня появилось стойкое желание зарефакторить свой проект

2. Список различных библиотек и приложений, написанных на Go:

http://code.google.com/p/go-wiki/wiki/Projects

Новое в Go 1.1

    В Go версии 1.1 обещают такую клевую штуку как thread-sanitizer. Эта штуковина в автоматическом режиме определяет race conditions в вашей программе. Так как в Go потоки создаются "с легкостью необыкновенной"  то и проблема обнаружения таких ошибок стоит весьма остро. Хотя если следовать паттернам проектирования реализованным в самом языке то вероятность наступить на эти грабли минимальна.  

 Как эта штуковина работает ? 

 Она патчит компилятор и при любом доступе к памяти, который является потенциально опасным  проверяет этот участок памяти - на предмет а не пишет ли кто туда в этот момент ?

Если такие вещи обнаруживается то вам выдается лог с указанием какие именно потоки у вас не поделили данный участок памяти.  Более подробно об алгоритме можно прочитать тут - https://code.google.com/p/thread-sanitizer/wiki/Algorithm 

     Этот инструмент в принципе доступен уже сейчас - для C/C++ и для Go. Но придется самим прикручивать его к компилятору. Самая же хорошая новость - что в Go 1.1 этот инструмент будет доступен сразу в коробке.