1.db.server.Status()
>>echo "db.serverStatus()" |mongo 127.0.0.1:27017 --quiet
{
"host" : "tong", --server的hostname
"version" : "4.4.0", --mongo版本
"process" : "mongod", --进程名
"uptime" : 8886, --启动时间（单位：S）
"uptimeEstimate" : 8885527, --基于MongoDB内部粗粒度定时器的运行时间
"localTime" : ISODate("2020-09-23T05:42:47.200Z"), --server的本地时间
"globalLock" : {
"totalTime" : 1238418105923, --全局锁创建的时间（单位：ms 微秒）
"lockTime" : 75055831911, --全局锁保持的时间（单位：ms 微秒）
"ratio" : 0.06060621332329477, --lockTime和totalTime的比
"currentQueue" : {
"total" : 0, --等待全局锁的队列中操作数目
"readers" : 0, --等待读锁的队列中操作数目
"writers" : 0 --等待写锁的队列中操作数目
},
"activeClients" : {
"total" : 1, --连接到server的当前活动client数目
"readers" : 1, --执行读操作的当前活动client数目
"writers" : 0 --执行写操作的当前活动client数目
}
},
"mem" : {
"bits" : 64, --64位机器
"resident" : 18363, --占用物理内存量。
"virtual" : 478810, --占用的虚拟内存量
"supported" : true, --是否支持扩展内存
"mapped" : 233311, --映射到内存的数据文件大小，很接近于你的所有数据库大小(mmap引擎才有)。
"mappedWithJournal" : 466622,
"note" : "virtual minus mapped is large. could indicate a memory leak"
},
"connections" : {
"current" : 737, --当前活动连接量。连接到server的当前活跃连接数目
"available" : 82 --剩余空闲连接量。剩余的可用连接数目
},
"extra_info" : {
"note" : "fields vary by platform",
"heap_usage_bytes" : 3838448, --此过程中所有的堆字节数目。仅适用于Linux
"page_faults" : 31058356 --此过程中访问内存中页面失败的总次数。仅适用于Linux
},
"indexCounters" : {
"btree" : {
"accesses" : 68229146, --Btree索引的访问次数（索引被访问量）
"hits" : 68229146, --内存中的Btree页的数目。（索引命中量）
"misses" : 0, --内存中不存在的Btree也数目。（索引偏差量）（索引内存访问失败次数）
"resets" : 0, --索引计数器被重置为0的次数
"missRatio" : 0 --索引偏差率（未命中率）
}
},
"backgroundFlushing" : {
"flushes" : 20640, --数据库刷新写到磁盘的次数
"total_ms" : 2453287, --数据库刷新数据到磁盘花费的微秒数
"average_ms" : 118.8608042635659, --执行单次刷新花费的平均微秒数
"last_ms" : 1, --最后一次执行完成刷新数据到磁盘花费的微秒数
"last_finished" : ISODate("2012-09-14T09:09:35.656Z") --当最后一次刷新数据完成时的时间戳
},
"cursors" : {
"totalOpen" : 0, --server为client保持的游标（cursor）总数
"clientCursors_size" : 0, --
"timedOut" : 24 --server启动以来游标（cursor）超时的总数
},
"network" : {
"bytesIn" : NumberLong("1929833164782"), --发送到数据库的数据总量（bytes）
"bytesOut" : 553137147925, --数据库发出的数据总量（bytes）
"numRequests" : 2475184328 --发送到数据库的请求量
},
"opcounters" : {
"insert" : 687531883, --server启动以来总的insert数据量
"query" : 711010343, --server启动以来总的query数据量
"update" : 0, --server启动以来总的update数据量
"delete" : 0, --server启动以来总的delete数据量
"getmore" : 6484, --server启动以来调用任何游标的getMore总次数
"command" : 1287537 --server启动以来执行其他命令的总次数
},
"asserts" : {
"regular" : 0, --server启动以来抛出正规断言（assert 类似于异常处理的形式）总数目
"warning" : 1, --server启动以来抛出的告警总数目
"msg" : 0, --消息断言数目。服务器内部定义的良好字符串错误
"user" : 4, --用户断言数目。用户产生的错误，譬如：磁盘空间满；重复键。
"rollovers" : 0 --server启动以来，assert counters have rolled over的次数
},
"writeBacksQueued" : false, --是否有从mongos执行的retry操作
"dur" : {
"commits" : 30, --上一间隔journal日志发生commit的次数
"journaledMB" : 0, --上一间隔写到journal日志的数据量（单位：MB）
"writeToDataFilesMB" : 0, --上一间隔journal日志写到数据文件的数据量（单位：MB）
"compression" : 0, --
"commitsInWriteLock" : 0, --写锁期间发生commits的次数
"earlyCommits" : 0, --schedule时间前请求commit的次数
"timeMs" : {
"dt" : 3064,
"prepLogBuffer" : 0, --准备写journal日志花费的时间
"writeToJournal" : 0, --写journal日志花费的实际时间
"writeToDataFiles" : 0, --journal日志后写数据文件花费的时间
"remapPrivateView" : 0 --The amount of time spent remapping copy-on-write memory mapped views
}
},
"ok" : 1 --serverStatus是否返回正确
"$clusterTime" : {
"clusterTime" : Timestamp(1600839763, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
},
"operationTime" : Timestamp(1600839763, 1)
}
2.关于mongodb连接数与内存
tongRepl:SECONDARY> db.serverStatus().connections
{
"current" : 13,
"available" : 2035,
"totalCreated" : 714,
"active" : 3,
"exhaustIsMaster" : 2,
"awaitingTopologyChanges" : 79
}
1.current：表示当前有多少客户端连接到了mongo服务端
2. available：可用连接数
3. totalCreated：总创建的连接数
4. active：当前活跃的连接数
5. exhaustIsMaster:已耗尽的isMaster请求的连接数。
6. awaitingTopologyChanges:当前在isMaster请求中等待拓扑改变的客户端数量。
3.linux缺省stack
1.stack：个人理解，就是程序使用递归操作时候，将数据放入堆栈中，一旦超出设定值就会触发Stack Overflow错误。
2.open file句柄值需要修改
有时候Linux系统默认的open files(文件句柄)是1024， 但是mongod官网建议是64000
查看堆栈设置大小（linux一般默认8MB）
[wantuser@SHQWANTAITEST02 ~]$ ulimit -a | grep stack
stack size (kbytes, -s) 8192
4.mongo查看用户进限制(kb)
mac查看stack大小
[wantuser@SHQWANTAITEST02 ~]$ cat /proc/$(pidof mongod)/limits | grep stack | awk -F 'size' '{print int($NF)/1024}'
8192
临时调整stack大小的方法
[root@f1-mongo1 journal]# ulimit -s 1024
查看stack、open file跟其他参数
tong@tongdembp goproj % ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 1392
-n: file descriptors 2560
永久调整Mongodb用户文件句柄数。
>>vi /etc/security/limits.conf
mongo soft nproc 64000
mongo hard nproc 64000
mongo soft nofile 64000
mongo hard nofile 64000
5.top查看
[wantuser@SHQWANTAITEST02 ~]$ top
top - 09:55:36 up 13 days, 14:24, 2 users, load average: 0.00, 0.02, 0.05
Tasks: 219 total, 1 running, 218 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16433084 total, 13704208 free, 1183664 used, 1545212 buff/cache
KiB Swap: 8257532 total, 8257532 free, 0 used. 14966964 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4329 wantuser 20 0 1095764 130168 9460 S 0.7 0.8 107:22.09 mongod
mac 命令行查看内存
echo -e "\n$(top -l 1 | awk '/PhysMem/';)\n"
Mongodb 的WiredTiger CacheSize
Mongodb的wiredtiger cacheSizeGB 指的就是Cache size，包括数据和索引。Mongod本身使用内存如连接池堆栈以及sorting buffer等都是额外的，不会被统计到这个数字里面。
如果索引在内存，查询冷数据取决于你的IO能力。如果IO latency很低，系统也没有是高负载，那响应时间应该是毫秒级的区别。但是如果查询很频繁，又涉及到很多范围、批量查询，IOPS又跟不上，那就有可能到几百几千毫秒都有可能。
6.linux的buffer/cache
buffer
即写如磁盘时，先保存到磁盘缓冲区(buffer)，然后再写入到磁盘。
cache
即读磁盘时，数据从磁盘读出后，暂留在缓冲区(cache)，为后续程序的使用做准备。
- 操作系统的角度：这块内存确实被操作系统使用了。
- 用户角度：如果用户要使用，这块内存是可以很快被回收而被用户空间程序使用，因此从用户角度而言这块内存应被划为空闲状态。
- 目的就是为了提升磁盘IO的性能，从低速的块设备上读取的数据会暂时保存在内存中，即使数据在当时已经不再需要了，但在应用程序下一次访问该数据时，它可以从内存中直接读取，绕开了低速的块设备，从而提高系统的整体性能。
为了提高系统性能和不浪费内存，linux把多的内存做了cache，以提高io速度.你的那些内存并没有被占用。
7.TCP连接和请求处理
mongodb 驱动与mongod进行tcp连接时，会发送数据库请求，数据库会接受应答。tcp协议栈为连接维护socket元数据，每个连接会有一个read buffer及write buffer,这里的rb和tb就表示相应的buffer
image.png
对于每个连接，Mongod 会起一个单独的线程，专门负责处理这条连接上的请求，mongod 为处理连接请求的线程配置了最大1MB的线程栈，通常实际使用在几十KB左右，通过 proc 文件系统看到这些线程栈的实际开销。 除了处理请求的线程，mongod 还有一系列的后台线程，比如主从同步、刷新 Journal、TTL、evict 页面淘汰等线程，默认每个线程最大ulimit -s（一般8MB）的线程栈，由于这批线程数量比较固定，占的内存也比较可控。
8.tcmalloc(New in version 4.2.3: Also available in 3.6.17+ and 4.0.14+)
并发高导致内存暴增，主要也是因为tcmalloc的机制
https://gperftools.github.io/gperftools/tcmalloc.html#runtime
查看mongodb的tcmalloc内存
db.serverStatus().tcmalloc
total_free_bytes表示是tcmalloc的空闲，并没返回给系统。
其他的都是tcmalloc在使用的的内存。
tcmalloc 为性能考虑，每个线程会有自己的 local free page cache，还有 central free page cache；内存申请时，按 local thread free page cache ==> central free page cache 查找可用内存，找不到可用内存时才会从堆上申请；当释放内存时，也会归还到 cache 里，tcmalloc 后台慢慢再归还给 OS，
默认情况下，tcmalloc 最多会 cache min（1GB，1/8 * system_memory） 的内存， 通过 setParameter.tcmallocMaxTotalThreadCacheBytesParameter 参数可以配置这个值
image.png
"formattedString" : "------------------------------------------------
MALLOC: 11885113240 (11334.5 MiB) Bytes in use by application
MALLOC: + 2490413056 ( 2375.0 MiB) Bytes in page heap freelist
MALLOC: + 773440096 ( 737.6 MiB) Bytes in central cache freelist
MALLOC: + 489728 ( 0.5 MiB) Bytes in transfer cache freelist
MALLOC: + 590923016 ( 563.5 MiB) Bytes in thread cache freelists
MALLOC: + 100851968 ( 96.2 MiB) Bytes in malloc metadata
MALLOC: ------------
MALLOC: = 15841231104 (15107.4 MiB) Actual memory used (physical + swap)
MALLOC: + 1233395712 ( 1176.3 MiB) Bytes released to OS (aka unmapped)
MALLOC: ------------
MALLOC: = 17074626816 (16283.6 MiB) Virtual address space used
MALLOC:
MALLOC: 1088636 Spans in use
MALLOC: 96 Thread heaps in use
MALLOC: 4096 Tcmalloc page size
------------------------------------------------
Call ReleaseFreeMemory() to release freelist memory to the OS (via madvise()).
Bytes released to the OS take up virtual address space but no physical memory.
eviction四个重要的参数
降低eviction_target、eviction_dirty_target，让evict线程提前将数据从wiredtiger cache刷到操作系统的page cache，可以提早刷盘。
eviction_target 80（实际就是cachesize的百分比）当cache_used超过80%时候，触发触发eviction，后台evict线程开始淘汰clean page。类似LRU算法，淘汰冷数据
eviction_trigger 95 cache used超过eviction_trigger，用户线程也开始淘汰CLEAN PAGE。
eviction_dirty_target 5 cache dirty超过eviction_dirty_target，evict线程开始淘汰DIRTY PAGE。
eviction_dirty_trigger 20 cache dirty超过eviction_dirty_trigger, 用户线程也开始淘汰DIRTY PAGE。
关于cachesize
默认情况下，cache_used超过80%将触发eviction，类似mysql的LRU算法冷数据的淘汰， 避免cache用量持续增长。 如果物理内存充足，设置足够大的cache_size，以加载全部数据，避免不必要的eviction。
cache_size:
cache_size = (data + index) / 0.8
eviction:
查看wiredTiger.cache一些参数。
db.serverStatus().wiredTiger.cache
"eviction worker thread active" 默认为 4,
对于eviction线程，MongoDB默认配置是eviction=(threads_min=1,threads_max=4)，根据cache使用情况，创建1-4个eviction线程去淘汰冷数据。
如果cache体积较大，或者机器性能很高。可以适当调高。
Example：
db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "eviction=(threads_min=1,threads_max=8)"})
wiredTigerConcurrentWriteTransactions
并发写事务数默认128
通过mongostat查看运行状态，如果qw持续较高、aw经常是128（默认值），说明写请求发生排队，同时WT无法提供更高的并发写。
image.png
查看wiredTigerConcurrentWriteTransactions配置
db.adminCommand({getParameter: 1, wiredTigerConcurrentWriteTransactions: 1})
image.png
