Dropping of Connections with Tcp_Tw_Recycle

Why is tcp_tw_reuse turned off by default?

Saw a great article on this today, that provides a really in depth answer that I thought anyone that ran across this question should have:

http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

After reviewing it, it looks like the change I made to use tcp_tw_reuse doesn't even impact incoming connections, so it appears that my original solution was a fruitless change on my part.

How to reliably measure the network bandwidth used by a process

Can the application be isolated on a single machine?

Does anything else have to run on the system?

If a system can be dedicated this way, periodically grab the last line from /proc/net/netstat and subtract the corresponding values of InOctets and OutOctets.

This system, Fedora 15, shows this after 23 days of uptime:

TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab DelayedACKs DelayedACKLocked DelayedACKLost ListenOverflows ListenDrops TCPPrequeued TCPDirectCopyFromBacklog TCPDirectCopyFromPrequeue TCPPrequeueDropped TCPHPHits TCPHPHitsToUser TCPPureAcks TCPHPAcks TCPRenoRecovery TCPSackRecovery TCPSACKReneging TCPFACKReorder TCPSACKReorder TCPRenoReorder TCPTSReorder TCPFullUndo TCPPartialUndo TCPDSACKUndo TCPLossUndo TCPLoss TCPLostRetransmit TCPRenoFailures TCPSackFailures TCPLossFailures TCPFastRetrans TCPForwardRetrans TCPSlowStartRetrans TCPTimeouts TCPRenoRecoveryFail TCPSackRecoveryFail TCPSchedulerFailed TCPRcvCollapsed TCPDSACKOldSent TCPDSACKOfoSent TCPDSACKRecv TCPDSACKOfoRecv TCPAbortOnSyn TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout TCPAbortOnLinger TCPAbortFailed TCPMemoryPressures TCPSACKDiscard TCPDSACKIgnoredOld TCPDSACKIgnoredNoUndo TCPSpuriousRTOs TCPMD6NotFound TCPMD5Unexpected TCPSackShifted TCPSackMerged TCPSackShiftFallback TCPBacklogDrop TCPMinTTLDrop TCPDeferAcceptDrop IPReversePathFilter TCPTimeWaitOverflow TCPReqQFullDoCookies TCPReqQFullDrop
TcpExt: 0 0 0 0 0 0 0 0 10 0 67116 0 0 0 0 8 117271 53 18860 0 0 102295 23352211 87967244 0 16861098 118195 893786 881659 0 29 10 0 0 0 9 10 16 12 2321 21 0 1 156 39 940 13 921 8015 0 1 2 0 18461 22 941 0 0 2974 15422 0 709 0 0 0 1 8 119 3 0 0 0 0 25231 0 0 0 4 0 0 0
IpExt: InNoRoutes InTruncatedPkts InMcastPkts OutMcastPkts InBcastPkts OutBcastPkts InOctets OutOctets InMcastOctets OutMcastOctets InBcastOctets OutBcastOctets
IpExt: 0 0 25308 48 725 1 24434248973 4218365129 2181277 13241 365505 65

Of course, that format is unfriendly for here, but fairly nice for scripting languages to deal with. You can see the depth and variety of information! The last line shows that this system has read 24,434,248,973 bytes and written 4,218,365,129. (It is on day nine of scraping a large website.)

Read binary stdout data like screencap data from adb shell?

Sorry to be posting an answer to an old question, but I just came across this problem myself and wanted to do it only through the shell. This worked well for me:

adb shell screencap -p | sed 's/^M$//' > screenshot.png

That ^M is a char I got by pressing ctrl+v -> ctrl+m, just noticed it doesn't work when copy-pasting.

adb shell screencap -p | sed 's/\r$//' > screenshot.png

did the trick for me as well.

How to see top processes sorted by actual memory usage?

First, repeat this mantra for a little while: "unused memory is wasted memory". The Linux kernel keeps around huge amounts of file metadata and files that were requested, until something that looks more important pushes that data out. It's why you can run:

find /home -type f -name '*.mp3'
find /home -type f -name '*.aac'

and have the second find instance run at ridiculous speed.

Linux only leaves a little bit of memory 'free' to handle spikes in memory usage without too much effort.

Second, you want to find the processes that are eating all your memory; in top use the M command to sort by memory use. Feel free to ignore the VIRT column, that just tells you how much virtual memory has been allocated, not how much memory the process is using. RES reports how much memory is resident, or currently in ram (as opposed to swapped to disk or never actually allocated in the first place, despite being requested).

But, since RES will count e.g. /lib/libc.so.6 memory once for nearly every process, it isn't exactly an awesome measure of how much memory a process is using. The SHR column reports how much memory is shared with other processes, but there is no guarantee that another process is actually sharing -- it could be sharable, just no one else wants to share.

The smem tool is designed to help users better gage just how much memory should really be blamed on each individual process. It does some clever work to figure out what is really unique, what is shared, and proportionally tallies the shared memory to the processes sharing it. smem may help you understand where your memory is going better than top will, but top is an excellent first tool.

---

Related Topics