lsof is a command meaning "list open files", which is used in many Unix-like systems to report a list of all open files and the processes that opened them. This open source utility was developed and supported by Victor A. Abell, the retired Associate Director of the Purdue University Computing Center.
pid from port
lsof -i @192.14.166.72:20000
open jar files:
lsof -p
Get the list of files opened
lsof –p
Get the count
lsof –p | wc –l
pid listening tcp at specific port:
lsof -i tcp:8888
lsof -i:22
From gist
#list all ports for tcp
sudo lsof -itcp
#find all things listening on ports
lsof -Pnl +M -i4 | grep LISTEN
#all ports for tcp, dont resolve port name from numbers
sudo lsof -itcp -P
#open files and ports of process #$PID
sudo lsof -p $PID
#only ports of tcp for process #$PID, dont resolve port name, dont resolve ip name
sudo lsof -a -p $PID -P -n -itcp
#only ports of tcp for process #$PID, dont resolve port name, dont resolve ip name, refresh every 5 seconds
sudo lsof -a -p $PID -P -n -itcp -r 5
#search by file (can be slow)
sudo lsof /complete/path/to/file
-XX:NewRatio
It is also possible to specify the young generation size in relation to the size of the old generation. The potential advantage of this approach is that the young generation will grow and shrink automatically when the JVM dynamically adjusts the total heap size at run time. The flag-XX:NewRatioallows us to specify the factor by which the old generation should be larger than the young generation. For example, with-XX:NewRatio=3the old generation will be three times as large as the young generation. That is, the old generation will occupy 3/4 and the young generation will occupy 1/4 of the heap.
If we mix absolute and relative sizing of the young generation, the absolute values always have precedence. Consider the following example:
With these settings, the JVM will try to size the young generation at one third of the old generation size, but it will never let young generation size fall below 32 MB or exceed 512 MB.
There is no general rule if absolute or relative young generation sizing is preferable. If we know the memory usage of our application well, it can be advantageous to specify a fixed size both for the total heap and the young generation, and it can also be useful to specify a ratio. If we only know a little or maybe nothing at all about our application in this respect, the correct approach is to just let the JVM do the work and not to mess around with the flags. If the application runs smoothly, we can be happy that we didn’t put in extra effort where none was needed. And should we encounter performance problems or OutOfMemoryErrors, we would still need to first perform a series of meaningful measurements to narrow down the root cause of the problem before moving on to tuning.
Each of the sequence of calculations is performed by having the first stage of the pipeline perform the first step, and then the second stage the second step, and so on.
As each stage completes a step of a calculation, it passes the calculation-in-progress to the next stage and begins work on the next calculation.”
