Change is required. Atlassian engineer's blog

  Hey! Gonchik, a lover of APM (application performance monitoring) tools, in particular Glowroot, is in touch. Today I will tell you how to find bottlenecks in Confluence On-Prem in the shortest possible time based on one industrial installation. We are faced with a situation where a large number of people simultaneously break into the knowledge base on Confluence On-Prem (during the certification), and the Confluence dies for some time. We immediately thought that the problem is precisely in the simultaneous number of visitors and we can immediately tweak the JVM, but it turned out that not everything is so simple. Below I will tell you how we found the real cause of the brakes and how we dealt with it. The main task: to conduct an audit and, on its basis, achieve performance improvements, especially in times of a large number of active users in the system. Of course, first of all, the hardware resources and OS configurations were checked, where no problems were identified. Howev...

  Привет!  На связи Гончик, любитель APM (application performance monitoring) инструментов, в частности Glowroot .  Сегодня расскажу о том, как за кратчайшее время найти узкие места в Confluence On-Prem на основе одной промышленной инсталляции.  Мы столкнулись с ситуацией, когда большое количество людей одновременно ломится в базу знаний на Confluence On-Prem (во время сдачи аттестации), и конфлюенс умирает на какое-то время. Сразу подумали, что проблема именно в одновременном количестве посетителей и сразу можно затюнить JVM, но оказалось, что не все так однозначно. Ниже расскажу, как мы нашли реальную причину тормозов и как с ней справились. Основная задача: провести аудит и на его основе добиться улучшения производительности, особенно в моменты большого количества активных пользователей в системе.  Конечно, в первую очередь были проверены ап паратные ресурсы, конфигурации ОС, где никаких проблем не выявлено.  Однако, отсутствовали access логи nginx, поск...

Hi community,    Today I would like to share a small snippet to investigate DB and RDBMS PostgreSQL.  Before starting to check and do “explain analyze” of slowest and frequent slow queries I do: select sum(xact_commit) as commits, sum(xact_rollback) as rollbacks from pg_stat_database; Just to understand how often we  meet with rollbacks. I do recommend to run a few times that query with a small timeout to understand frequency.    Next one is used and remained connections  query : select max_conn,used,res_for_super,max_conn-used-res_for_super res_for_normal from  (select count(*) used from pg_stat_activity) t1,  (select setting::int res_for_super from pg_settings where name=$$superuser_reserved_connections$$) t2,  (select setting::int max_conn from pg_settings where name=$$max_connections$$) t3; After we are ready to check the  status of connections . Helpful to plan pooling. with states as    (select datname, client_a...