When I type vmstat -m in command line, it shows:
Cache Num Total Size Pages
fuse_request 0 0 424 9
fuse_inode 0 0 768 5
pid_2 0 0 128 30
nfs_direct_cache 0 0 200 19
nfs_commit_data 0 0 704 11
nfs_write_data 36 36 960 4
nfs_read_data 0 0 896 4
nfs_inode_cache 8224 8265 1048 3
nfs_page 0 0 128 30
fscache_cookie_jar 2 48 80 48
rpc_buffers 8 8 2048 2
rpc_tasks 8 15 256 15
rpc_inode_cache 17 24 832 4
bridge_fdb_cache 14 59 64 59
nf_conntrack_expect 0 0 240 16
For the nfs_write_data line(line 7), why the "pages" is less than "total"?
For some of them, the "total" is always equal to "pages".
Taken from vmstat man page
...
The -m switch displays slabinfo.
...
Field Description For Slab Mode
cache: Cache name
num: Number of currently active objects
total: Total number of available objects
size: Size of each object
pages: Number of pages with at least one active object
totpages: Total number of allocated pages
pslab: Number of pages per slab
Thus, total is the number of slabinfo objects (objects used by the OS as inodes, buffers and so on) and a page can contain more than one object
Related
I am seeing high CPU and memory usage of cassandra on the seed node. Is it advisable to stop compaction(nodetool stop) and enable in offpeak hours. Should I do manual compaction or enable autocompaction. I see lot of Native-Transport-Requests. I have three seed nodes. This is the first seed node.
Pool Name Active Pending Completed Blocked All time blocked
ReadStage 0 0 54255 0 0
MiscStage 0 0 0 0 0
CompactionExecutor 2 2566 352765 0 0
MutationStage 0 0 2659921760 0 0
MemtableReclaimMemory 0 0 180958 0 0
PendingRangeCalculator 0 0 21 0 0
GossipStage 0 0 338375 0 0
SecondaryIndexManagement 0 0 0 0 0
HintsDispatcher 0 0 63 0 0
RequestResponseStage 0 1 1684328696 0 0
Native-Transport-Requests 4 0 1538523706 0 47006391
ReadRepairStage 0 0 2197 0 0
CounterMutationStage 0 0 0 0 0
MigrationStage 0 0 0 0 0
MemtablePostFlush 1 1 216220 0 0
PerDiskMemtableFlushWriter_0 1 1 180958 0 0
ValidationExecutor 0 0 33250 0 0
Sampler 0 0 0 0 0
MemtableFlushWriter 1 1 180958 0 0
InternalResponseStage 0 0 141677 0 0
ViewMutationStage 0 0 0 0 0
AntiEntropyStage 0 0 166254 0 0
CacheCleanupExecutor 0 0 0 0 0
Repair#9 0 0 5719 0 0
I do see high compactions. Is it advisable to disable compactions using nodetool stop
$ nodetool info
ID : ebeda774-cea8-40bb-9322-69c6fcded5a9
Gossip active : true
Thrift active : true
Native Transport active: true
Load : 535.37 GiB
Generation No : 1636316595
Uptime (seconds) : 73152
Heap Memory (MB) : 19542.18 / 32168.00
Off Heap Memory (MB) : 1337.98
Data Center : us-west2
Rack : a
Exceptions : 15
Key Cache : entries 152283, size 23.07 MiB, capacity 100 MiB, 23835 hits, 280738 requests, 0.085 recent hit rate, 14400 save period in seconds
Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds
Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
Chunk Cache : entries 6782, size 423.88 MiB, capacity 480 MiB, 23947952 misses, 24381819 requests, 0.018 recent hit rate, 250.977 microseconds miss latency
Percent Repaired : 0.49796724500672584%
Token : (invoke with -T/--tokens to see all 256 tokens)
$ free -h
total used free shared buff/cache available
Mem: 62G 53G 658M 1.0M 8.5G 8.5G
Swap: 0B 0B 0B
~$ nodetool compactionstats
pending tasks: 197
....
id compaction type keyspace table completed total unit progress
5e555610-40b2-11ec-9b5a-27bc920e6e55 Compaction mykeyspace table1 27299674 89930474 bytes 30.36%
5e55f251-40b2-11ec-9b5a-27bc920e6e55 Compaction mykeyspace table2 13922048 74426264 bytes 18.71%
Active compaction remaining time : 0h00m02s
I would definitely not run compaction manually. Much of the compaction thresholds are file-size based, which means that forcing it creates files sized outside of the normal progression. The result, is that the chances of compaction running on that table again are extremely slim. Basically, once you start down that path, you'll be running manual compactions forever.
I would also say that compaction is a good thing. You want it to happen, as compacted files are necessary to keep reads performing well. Of course, that's not much of a consolation when the compaction process is affecting operational activity.
tl;dr;
One I have done in the past, is to lower compaction throughput during the day. Not sure what throughput you're running with currently, but you can find this out by running nodetool getcompactionthroughput:
% bin/nodetool getcompactionthroughput
Current compaction throughput: 64 MB/s
So at the times when customer/operational traffic is high, you can reduce that significantly:
% bin/nodetool setcompactionthroughput 1
% bin/nodetool getcompactionthroughput
Current compaction throughput: 1 MB/s
1 MB / second is the lowest that compaction throughput can be set. If you set it to zero, it's "un-throttled," which means it'll consume all the resources that it can get at. Setting it to 1 brings its resource use (and speed) down to a trickle.
Once the busy daily traffic subsides, that setting can be turned back up:
% bin/nodetool setcompactionthroughput 256
Current compaction throughput: 256 MB/s
This can be accomplished with a scheduled job for each command.
Running into an issue with DSE 4.7.
The tombstones are not being deleted even after compactions, cleanup, rebuild_index and repair. records have a 15 day ttl.
sstablemetadata output suggests that there are 90% tombstones
Any ideas?
sstablemetadata output
SSTable: ./abcd-abcd-ka-478675
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.010000
Minimum timestamp: 1527521280829593
Maximum timestamp: 1527596173976435
SSTable max local deletion time: 1528892173
Compression ratio: 0.36967428395684393
Estimated droppable tombstones: 0.9073013816277629
SSTable Level: 0
Repaired at: 0
ReplayPosition(segmentId=1520529283052, position=4626679)
Estimated tombstone drop times:%n
1528817679: 18318196
1528818619: 20753822
1528819513: 24176310
.
.
.
Count Row Size Cell Count
1 0 0
2 0 1752560
3 0 0
4 0 6355421
5 0 0
6 0 687302
7 0 0
8 0 529613
10 0 444801
12 0 410107
14 0 456011
17 0 1347893
20 0 184960
24 0 152814
.
.
.
770 1347893 137
924 184960 109
1109 220403 68
1331 121620 86
1597 2044030 102
1916 185601 195
2299 184816 158273
2759 868754 0
3311 62795 0
3973 1668 0
4768 2143 0
5722 1812541 0
6866 828 0
.
.
.
Ancestors: [476190, 474027, 475201, 478160]
Estimated cardinality: 20059264
Cassandra marks TTL data with a tombstone after the requested amount of time has expired. A tombstone exists for gc_grace_seconds. After data is marked with a tombstone, the data is automatically removed during the normal compaction process.
you can try to run major compaction to evict tombstone out.
Tombstones gets deleted after normal compaction. But, still sometime you find stale data (even in prod)in tombstone.The reason could be out of all the nodes in that cluster one is down and the data from tombstone did not got deleted because of that node. Also sometimes null values are inserted in primary key causing tombstone data.
I am new to SCTP protocol and trying to figure out how to interpret the SCTP stats captured by /proc/net/sctp
The output shows something like this.
2016-04-26 07:21:17
ASSOC SOCK STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC wmema wmemq sndbuf rcvbuf
ce0f1800 cd7ede00 2 1 3 11661 1783 423 0 77 292723 36422 36423 10.205.8.71 <-> *10.205.8.72 3000 10 10 10 0 0 0 873 704 163840 163840
ca625800 cd7ec000 2 1 3 65210 1 0 0 77 10344 3223 36412 10.205.8.71 <-> *10.205.0.135 3000 2 2 10 0 0 3 1 0 163840 163840
ENDPT SOCK STY SST HBKT LPORT UID INODE LADDRS
ca511d80 cd7ec3c0 2 10 40 36422 77 10345 10.205.8.71
ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX START
10.205.8.72 1783 1 200 5 0 0
10.205.0.135 1 1 200 15 0 0
SctpCurrEstab 2
SctpActiveEstabs 21
SctpPassiveEstabs 1855
SctpAborteds 272
SctpShutdowns 1808
SctpOutOfBlues 0
SctpChecksumErrors 0
SctpOutCtrlChunks 79214
SctpOutOrderChunks 327396
SctpOutUnorderChunks 0
SctpInCtrlChunks 268038
SctpInOrderChunks 174268
SctpInUnorderChunks 0
SctpFragUsrMsgs 0
SctpReasmUsrMsgs 0
SctpOutSCTPPacks 406626
SctpInSCTPPacks 385959
SctpT1InitExpireds 0
SctpT1CookieExpireds 0
SctpT2ShutdownExpireds 0
SctpT3RtxExpireds 5
SctpT4RtoExpireds 0
SctpT5ShutdownGuardExpireds 0
SctpDelaySackExpireds 9869
SctpAutocloseExpireds 0
SctpT3Retransmits 5
SctpPmtudRetransmits 0
SctpFastRetransmits 14
SctpInPktSoftirq 384346
SctpInPktBacklog 1613
SctpInPktDiscards 0
SctpInDataChunkDiscards 0
Can some one help me understand this or provide the link where i can get some information.
Thanks,
Vishal
The linux man page for SCTP (http://linux.die.net/man/7/sctp) has most of them covered - for example:
SctpChecksumErrors
The number of SCTP packets received with an invalid checksum.
SctpOutCtrlChunks
The number of SCTP control chunks sent (retransmissions are not included). Control chunks are those chunks different from DATA.
SctpOutOrderChunks
The number of SCTP ordered data chunks sent (retransmissions are not included).
SctpOutUnorderChunks
If there is a particular one you were wondering about, maybe let us know?
hi I am a Linux programmer
I have an order that monitor process cpus usage, so I use data on /proc/[pid]/stat № 14 and 15. That values are called utime and stime.
Example [/proc/[pid]/stat]
30182 (TTTTest) R 30124 30182 30124 34845 30182 4218880 142 0 0 0 5274 0 0 0 20 0 1 0 55611251 17408000 386 18446744073709551615 4194304 4260634 140733397159392 140733397158504 4203154 0 0 0 0 0 0 0 17 2 0 0 0 0 0 6360520 6361584 33239040 140733397167447 140733397167457 140733397167457 140733397168110 0
State after 5 sec
30182 (TTTTest) R 30124 30182 30124 34845 30182 4218880 142 0 0 0 5440 0 0 0 20 0 1 0 55611251 17408000 386 18446744073709551615 4194304 4260634 140733397159392 140733397158504 4203154 0 0 0 0 0 0 0 17 2 0 0 0 0 0 6360520 6361584 33239040 140733397167447 140733397167457 140733397167457 140733397168110 0
In test environment, this file refreshed 1 ~ 2 sec, so I assume this file often updated by system at least 1 sec.
So I use this calculation
process_cpu_usage = ((utime - old_utime) + (stime - old_stime))/ period
In case of above values
33.2 = ((5440 - 5274) + (0 - 0)) / 5
But, In commercial servers environment, process run with high load (cpu and file IO), /proc/[pid]/stat file update period increasing even 20~60 sec!!
So top/htop utility can't measure correct process usage value.
Why is this phenomenon occurring??
Our system is [CentOS Linux release 7.1.1503 (Core)]
Most (if not all) files in the /proc filesystem are special files, their content at any given moment reflect the actual OS/kernel data at that very moment, they're not files with contents periodically updated. See the /proc filesystem doc.
In particular the /proc/[pid]/stat content changes whenever the respective process state changes (for example after every scheduling event) - for processes mostly sleeping the file will appear to be "updated" at slower rates while for active/running processes at higher rates on lightly loaded systems. Check, for example, the corresponding files for a shell process which doesn't do anything and for a browser process playing some video stream.
On heavily loaded systems with many processes in the ready state (like the one mentioned in this Q&A, for example) there can be scheduling delays making the file content "updates" appear less often despite the processes being ready/active. Such conditions seem to be more often encountered in commercial/enterprise environments (debatable, I agree).
I want to ensure that all system threads in Linux run on core 0, leaving all the other cores to my application. I am using RHEL 6 and I have added the following lines at the top of /etc/rc.d/rc.sysinit:
taskset -p 0x01 1
taskset -p 0x01 2
taskset -p 0x01 $$
I still see a lot of threads/processes with PPID 2 running on cores other than 0. This indicates that kthreadd (the process with PID 2) spawns others before the above statements are executed. How can I ensure that all children of process 2 also run of core 0?
Edit: Here are, for example, the threads on core 4. Can any of these be moved away from core 4?
~> ps -L -eo pid,ppid,tid,nlwp,tty,comm,psr | grep 4$
PID PPID TID NLWP TT COMMAND PSR <-line added
15 2 15 1 ? migration/4 4
16 2 16 1 ? ksoftirqd/4 4
17 2 17 1 ? watchdog/4 4
31 2 31 1 ? events/4 4
46 2 46 1 ? kintegrityd/4 4
54 2 54 1 ? kblockd/4 4
65 2 65 1 ? ata/4 4
88 2 88 1 ? aio/4 4
96 2 96 1 ? crypto/4 4
420 2 420 1 ? ext4-dio-unwrit 4
879 2 879 1 ? kdmflush 4
926 2 926 1 ? ext4-dio-unwrit 4
935 2 935 1 ? ext4-dio-unwrit 4
1632 2 1632 1 ? rpciod/4 4
Some kernel threads were bound to their special (logic)CPU to do some work related that CPU, You can't migrate those kernel threads from their CPU. What you can do is migrating and pinning all the other tasks.
I guess this strange requirement is not your final purpose, and this(the title) is not the right approach to your purpose. If you provide your final purpose, guys in the SO can help you.