- Command to see what is the maximum number of connections that we have pulled so far (spike)
1
$ grep HikariPool-1 system.log.*| grep "cleanup stats" | awk 'BEGIN{FS=",";RS="active="}''{print $1}'| sort -rn| uniq | head -1
Command to see number of active connections group by count
This is to investigate what should be the correct minimum idle count
1
$ grep HikariPool-1 system.log.*| grep "cleanup stats" | awk 'BEGIN{FS=",";RS="active="}''{print $1}'| uniq -cd | sort -nr
- Command to see the status of connection pool at this instance
1
$ tail -f system.log | grep HikariPool-1
wait for 30 seconds (default) for status to appear on terminal.
Command to see connection leaks
1
2
3
4
5
6
7
8
9
10
11
$ grep LeakTask system.log | sort -t- -nk4 | awk 'BEGIN{RS="task-"}''{print "task-" $1 " " $3}'
task-111, trace
task-111, returned
task-121, trace
task-121, returned
task-131, trace
task-141, trace
task-222, trace
task-222, returned
In the above scenario the task-131 and task-141 were never returned to the pool
When you look for task-131 and task-141 in logs you will see where they originate from:
1
$ grep -A 10 -B 10 "task\\-131\|task\\-141" system.log
com.x.run.Upload.doPost(Upload.java:22)
next step is to do code analysis to see why this piece of code did not release connections.