记一次mogodb占用cpu高问题
公司服务器上安装了contly，是一个开源的node.js项目，用于统计手机app使用情况，后端数据储存使用的mongodb，使用的时候经常发现mongodb占用cpu非常高，打到了210%的爆表值
top - :: up days, :, users, load average: 2.84, 2.96, 2.93
Tasks: total, running, sleeping, stopped, zombie
%Cpu(s): 59.4 us, 2.7 sy, 0.0 ni, 36.9 id, 0.2 wa, 0.7 hi, 0.0 si, 0.0 st
KiB Mem: total, used, free, buffers
KiB Swap: total, used, free. cached Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
root .452g .643g .490g S 210.5 33.9 : mongod
root S 5.0 1.3 :07.08 nodejs
root S 5.0 1.4 :19.13 nodejs
root S 4.0 1.4 :16.49 nodejs
root S 4.0 4.7 :00.97 nodejs
www-data S 1.0 0.0 :47.74 nginx
www-data S 1.0 0.0 :54.43 nginx
www-data S 1.0 0.0 :46.74 nginx
www-data S 1.0 0.0 :40.89 nginx
root R 0.7 0.0 :00.23 top
root S 0.3 0.0 : rcu_sched
root S 0.3 0.0 :02.41 rcuos/
root S 0.3 2.7 :37.95 jsvc
root S 0.0 0.0 :19.37 init
root S 0.0 0.0 :02.51 kthreadd
root S 0.0 0.0 :42.78 ksoftirqd/
root - S 0.0 0.0 :00.00 kworker/:0H
root S 0.0 0.0 :56.62 rcuos/
root S 0.0 0.0 :26.86 rcuos/
root S 0.0 0.0 :57.90 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcuos/
root S 0.0 0.0 :00.00 rcu_bh
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
root S 0.0 0.0 :00.00 rcuob/
仔细查看是中断很多，命令是pid -w 1
root@localhost:~# pidstat -w
Linux 3.13.--generic (localhost) // _x86_64_ ( CPU) :: PM UID PID cswch/s nvcswch/s Command
:: PM 260.40 0.00 rcu_sched
:: PM 78.22 0.00 rcuos/
:: PM 49.50 0.00 rcuos/
:: PM 88.12 0.00 rcuos/
:: PM 96.04 0.00 rcuos/
:: PM 0.99 0.00 watchdog/
:: PM 0.99 0.00 watchdog/
:: PM 7.92 0.00 ksoftirqd/
:: PM 0.99 0.00 watchdog/
:: PM 39.60 0.00 ksoftirqd/
:: PM 0.99 0.00 watchdog/
:: PM 9.90 0.00 ksoftirqd/
:: PM 7.92 0.00 kworker/u64:
:: PM 0.99 4.95 pidstat
:: PM 0.99 0.00 supervisord
:: PM 9.90 0.00 vmtoolsd
:: PM 0.99 0.00 fail2ban-server
:: PM 18.81 0.00 xfsaild/sdb1
:: PM 9.90 0.00 kworker/:1H
:: PM 0.99 0.00 kworker/:
:: PM 0.99 0.00 kworker/:
:: PM 0.99 0.00 zabbix_agentd
:: PM 0.99 0.00 zabbix_agentd
:: PM 154.46 0.00 nginx
:: PM 178.22 0.00 nginx
:: PM 166.34 0.00 nginx
:: PM 168.32 0.00 nginx
:: PM 100.00 0.00 mongod
:: PM 0.99 0.00 supervisord
:: PM 126.73 39.60 nodejs
:: PM 141.58 46.53 nodejs
:: PM 137.62 110.89 nodejs
:: PM 123.76 96.04 nodejs
:: PM 6.93 0.00 kworker/:
:: PM 0.99 0.00 kworker/:
vmstat
root@localhost:~# vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
中断和上下文切换多，是因为nodejs一直在被从sleep中唤醒，实际上是countly要接受手机端返回来的数据，不断被IO唤醒，每次唤醒都要上下文切换，所以表象是上下文频繁切换，实质上是counly负担比较重。
不过这个貌似和mongodb没有关系，只能说明countly的负担比较重，一直在写入mongodb，所以现在mongodb的负担也比较大。其实io算不上高，cpu的iowait也不多，硬盘写入并不是瓶颈，可能是mongodb本身的问题
查看mongostat
root@localhost:~# mongostat
connected to: 127.0.0.1
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn time
| 24g .5g .64g countly:11.9% | | 102k 67k ::
| 24g .5g .65g countly:6.5% | | 255k 177k ::
| 24g .5g .63g countly:20.7% | | 807k 965k ::
| 24g .5g .65g countly:1.7% | | 88k 92k ::
| 24g .5g .58g countly:2.1% | | 77k 115k ::
| 24g .5g .64g countly:2.2% | | 106k 89k ::
| 24g .5g .66g countly:7.9% | | 96k 105k ::
| 24g .5g .66g countly:3.6% | | 184k 224k ::
| 24g .5g .67g countly:16.4% | | 440k 559k ::
| 24g .5g .65g countly:2.0% | | 67k 61k ::
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn time
| 24g .5g .66g countly:5.0% | | 119k 126k ::
| 24g .5g .65g countly:18.5% | | 414k 623k ::
| 24g .5g .65g countly:1.4% | | 49k 40k ::
| 24g .5g .64g countly:4.8% | | 145k 187k ::
| 24g .5g .66g countly:5.5% | | 141k 126k ::
| 24g .5g .65g countly:4.4% | | 84k 103k ::
| 24g .5g .63g countly:5.8% | | 125k 96k ::
| 24g .5g .61g countly:49.2% | | 1m 2m ::
| 24g .5g .68g countly:14.3% | | 647k 652k ::
| 24g .5g .65g countly:3.5% | | 87k 95k ::
insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn time
| 24g .5g .65g countly:7.4% | | 104k 104k ::
* | 24g .5g .64g countly:12.6% | | 65k 75k ::
* | 24g .5g .64g countly:2.4% | | 93k 110k ::
| 24g .5g .63g countly:1.9% | | 85k 103k ::
| 24g .5g .63g countly:2.9% | | 157k 247k ::
| 24g .5g .64g countly:1.6% | | 62k 78k ::
* | 24g .5g .59g countly:5.4% | | 101k 147k ::
| 24g .5g .63g countly:3.7% | | 90k 80k ::
| 24g .5g .58g countly:4.0% | | 72k 108k ::
| 24g .5g .67g countly:25.3% | | 492k 654k ::
mongodb的锁很多，怀疑是因为写入慢，一直在等待，浪费了大量的cpu时间
进入到mongodb中查看
root@localhost:~# mongo
MongoDB shell version: 2.4.
connecting to: test
> db.serverStatus()
{
"host" : "localhost",
"version" : "2.4.14",
"process" : "mongod",
"pid" : ,
"uptime" : ,
"uptimeMillis" : NumberLong(),
"uptimeEstimate" : ,
"localTime" : ISODate("2017-07-14T06:12:34.348Z"),
"asserts" : {
"regular" : ,
"warning" : ,
"msg" : ,
"user" : ,
"rollovers" :
},
"backgroundFlushing" : {
"flushes" : ,
"total_ms" : ,
"average_ms" : 248.01349679016164,
"last_ms" : ,
"last_finished" : ISODate("2017-07-14T06:12:27.580Z")
},
"connections" : {
"current" : ,
"available" : ,
"totalCreated" : NumberLong()
},
"cursors" : {
"totalOpen" : ,
"clientCursors_size" : ,
"timedOut" : ,
"totalNoTimeout" :
},
"dur" : {
"commits" : ,
"journaledMB" : 0.28672,
"writeToDataFilesMB" : 0.272729,
"compression" : 0.9344831856907262,
"commitsInWriteLock" : ,
"earlyCommits" : ,
"timeMs" : {
"dt" : ,
"prepLogBuffer" : ,
"writeToJournal" : ,
"writeToDataFiles" : ,
"remapPrivateView" :
}
},
"extra_info" : {
"note" : "fields vary by platform",
"heap_usage_bytes" : ,
"page_faults" :
},
"globalLock" : {
"totalTime" : NumberLong(""),
"lockTime" : NumberLong(""),
"currentQueue" : {
"total" : ,
"readers" : ,
"writers" :
},
"activeClients" : {
"total" : ,
"readers" : ,
"writers" :
}
},
"indexCounters" : {
"accesses" : ,
"hits" : ,
"misses" : ,
"resets" : ,
"missRatio" :
},
"locks" : {
"." : {
"timeLockedMicros" : {
"R" : NumberLong(),
"W" : NumberLong("")
},
"timeAcquiringMicros" : {
"R" : NumberLong(),
"W" : NumberLong()
}
},
"admin" : {
"timeLockedMicros" : { },
"timeAcquiringMicros" : { }
},
"local" : {
"timeLockedMicros" : {
"r" : NumberLong(),
"w" : NumberLong()
},
"timeAcquiringMicros" : {
"r" : NumberLong(),
"w" : NumberLong()
}
},
"countly" : {
"timeLockedMicros" : {
"r" : NumberLong(""),
"w" : NumberLong("")
},
"timeAcquiringMicros" : {
"r" : NumberLong(""),
"w" : NumberLong("")
}
},
"countly_drill" : {
"timeLockedMicros" : {
"r" : NumberLong(),
"w" : NumberLong("")
},
"timeAcquiringMicros" : {
"r" : NumberLong(),
"w" : NumberLong()
}
},
"test" : {
"timeLockedMicros" : {
"r" : NumberLong(),
"w" : NumberLong()
},
"timeAcquiringMicros" : {
"r" : NumberLong(),
"w" : NumberLong()
}
}
},
"network" : {
"bytesIn" : ,
"bytesOut" : ,
"numRequests" :
},
"opcounters" : {
"insert" : ,
"query" : ,
"update" : ,
"delete" : ,
"getmore" : ,
"command" :
},
"opcountersRepl" : {
"insert" : ,
"query" : ,
"update" : ,
"delete" : ,
"getmore" : ,
"command" :
},
"recordStats" : {
"accessesNotInMemory" : ,
"pageFaultExceptionsThrown" : ,
"countly" : {
"accessesNotInMemory" : ,
"pageFaultExceptionsThrown" :
},
"countly_drill" : {
"accessesNotInMemory" : ,
"pageFaultExceptionsThrown" :
},
"local" : {
"accessesNotInMemory" : ,
"pageFaultExceptionsThrown" :
},
"test" : {
"accessesNotInMemory" : ,
"pageFaultExceptionsThrown" :
}
},
"writeBacksQueued" : false,
"mem" : {
"bits" : ,
"resident" : ,
"virtual" : ,
"supported" : true,
"mapped" : ,
"mappedWithJournal" :
},
"metrics" : {
"document" : {
"deleted" : NumberLong(),
"inserted" : NumberLong(),
"returned" : NumberLong(),
"updated" : NumberLong()
},
"getLastError" : {
"wtime" : {
"num" : ,
"totalMillis" :
},
"wtimeouts" : NumberLong()
},
"operation" : {
"fastmod" : NumberLong(),
"idhack" : NumberLong(),
"scanAndOrder" : NumberLong()
},
"queryExecutor" : {
"scanned" : NumberLong()
},
"record" : {
"moves" : NumberLong()
},
"repl" : {
"apply" : {
"batches" : {
"num" : ,
"totalMillis" :
},
"ops" : NumberLong()
},
"buffer" : {
"count" : NumberLong(),
"maxSizeBytes" : ,
"sizeBytes" : NumberLong()
},
"network" : {
"bytes" : NumberLong(),
"getmores" : {
"num" : ,
"totalMillis" :
},
"ops" : NumberLong(),
"readersCreated" : NumberLong()
},
"oplog" : {
"insert" : {
"num" : ,
"totalMillis" :
},
"insertBytes" : NumberLong()
},
"preload" : {
"docs" : {
"num" : ,
"totalMillis" :
},
"indexes" : {
"num" : ,
"totalMillis" :
}
}
},
"ttl" : {
"deletedDocuments" : NumberLong(),
"passes" : NumberLong()
}
},
"ok" :
}
锁确实比较多，查看mongotop
root@localhost:/mnt/mongodb/log# mongotop
connected to: 127.0.0.1 ns total read write --14T06::
countly.online_users55d2e563292d6b2c7d1d132d 1669ms 1665ms 4ms
countly.online_users5770b587f4a7f02a6a2b9cce 53ms 52ms 1ms
countly.carriers 42ms 0ms 42ms
countly.online_users5506ab1979a3a67e5214cda6 40ms 38ms 2ms
countly.devices 16ms 0ms 16ms
countly.apps 9ms 9ms 0ms
countly.users 8ms 0ms 8ms
countly.device_details 7ms 0ms 7ms
countly.app_users55d2e563292d6b2c7d1d132d 4ms 0ms 4ms ns total read write --14T06::
countly.online_users55d2e563292d6b2c7d1d132d 3671ms 3669ms 2ms
countly.online_users5770b587f4a7f02a6a2b9cce 64ms 63ms 1ms
countly.online_users5506ab1979a3a67e5214cda6 26ms 25ms 1ms
countly.devices 19ms 0ms 19ms
countly.carriers 16ms 0ms 16ms
countly.users 6ms 0ms 6ms
countly.apps 6ms 6ms 0ms
countly.app_users55d2e563292d6b2c7d1d132d 4ms 1ms 3ms
countly_drill.drill_eventse02cd05a335f76036692df25f94be2b3d5c20bd2 3ms 0ms 3ms ns total read write --14T06::
countly.online_users55d2e563292d6b2c7d1d132d 1709ms 1705ms 4ms
countly.online_users5506ab1979a3a67e5214cda6 33ms 31ms 2ms
countly.carriers 19ms 0ms 19ms
countly.devices 10ms 0ms 10ms
countly.users 10ms 0ms 10ms
countly.online_users54feb14879a3a67e52f6f7cd 7ms 7ms 0ms
countly.apps 5ms 5ms 0ms
countly.app_users55d2e563292d6b2c7d1d132d 4ms 0ms 4ms
countly_drill.drill_eventsbb446ae67767dec699789c496e6c067b32dee999 3ms 0ms 3ms ns total read write --14T06::
countly.online_users55d2e563292d6b2c7d1d132d 2301ms 2298ms 3ms
countly.online_users5770b587f4a7f02a6a2b9cce 262ms 261ms 1ms
countly.online_users5506ab1979a3a67e5214cda6 35ms 34ms 1ms
countly_drill.drill_eventse02cd05a335f76036692df25f94be2b3d5c20bd2 22ms 0ms 22ms
countly.online_users54feb14879a3a67e52f6f7cd 8ms 7ms 1ms
countly.users 7ms 0ms 7ms
countly_drill.drill_eventscc860280b73e64c3413b38f2e9959acb7babd3f9 6ms 0ms 6ms
countly.app_users55d2e563292d6b2c7d1d132d 5ms 2ms 3ms
countly.apps 4ms 4ms 0ms
是读的时间很长，这个怀疑是没有建立索引，另外mongodb本身有一个bug
https://docs.mongodb.com/manual/administration/production-notes/
解决方法如下所示
#numactl --interleave all command
原理如下
http://www.cnblogs.com/Lifehacker/p/database_swap_insanity_on_Linux.html
这么操作了好像也没什么效果，最后想到之前这个数据库因为磁盘爆满清空过，之前听说过mongodb迁移后会丢失索引，要重建索引，我查了一下索引
> db.online_users55d2e563292d6b2c7d1d132d.find()
{ "_id" : "4e5d3922-6553-430a-849f-8b1007373d7c", "la" : ISODate("2017-06-30T00:55:08.933Z"), "n" : }
{ "_id" : "55d7d514-f75c-432a-b557-17c036437a32", "la" : ISODate("2017-06-29T16:38:12.863Z"), "n" : }
{ "_id" : "0118022e-54d2-4fb9-998d-a544d9a76d42", "la" : ISODate("2017-07-05T17:17:44.307Z"), "n" : }
{ "_id" : "2a160945-fcc1-42f5-8fd5-693f97c4c332", "la" : ISODate("2017-07-02T07:01:35.619Z"), "n" : }
{ "_id" : "14cd09d4-fd09-43b8-9259-8a007fc08b45", "la" : ISODate("2017-06-28T01:23:29.400Z"), "n" : }
{ "_id" : "b9fa7cc9-cd8c-4a1b-83fb-fc4c4f929715", "la" : ISODate("2017-06-26T13:38:32.887Z"), "n" : }
{ "_id" : "1d968b85-2571-4cf7-9520-bfeb44d893bc", "la" : ISODate("2017-07-13T13:08:18.807Z"), "n" : }
{ "_id" : "0b1a3d07-8e5d-4e78-a93f-d13811a81b86", "la" : ISODate("2017-07-13T03:10:39.927Z"), "n" : }
{ "_id" : "18d8f9fb-dff3-46e6-a3c7-bb19db748c4a", "la" : ISODate("2017-07-08T17:59:37.518Z"), "n" : }
{ "_id" : "a81349ac-9d83-4ef7-be0b-1b9bf64f867f", "la" : ISODate("2017-07-13T23:27:35.174Z"), "n" : }
{ "_id" : "dd841258-36a6-45de-bc45-450441d9bf33", "la" : ISODate("2017-07-14T06:34:23.838Z"), "n" : }
{ "_id" : "75720c9f-69af-4833-ae14-78a381cc31b6", "la" : ISODate("2017-07-13T15:57:28.700Z"), "n" : }
{ "_id" : "ef37ff3d-979d-4275-9991-398ccb2d5576", "la" : ISODate("2017-07-14T04:45:38.872Z"), "n" : }
{ "_id" : "465f923e-b0f1-4aa7-8f68-2d7db95973b2", "la" : ISODate("2017-07-07T11:47:53.029Z"), "n" : }
{ "_id" : "e6b5fd38-bb56-4634-9232-7eeceb8cf46a", "la" : ISODate("2017-07-09T03:27:04.545Z"), "n" : }
{ "_id" : "d4957c5d-154f-4c4f-8843-9792beab4817", "la" : ISODate("2017-07-11T21:49:35.417Z"), "n" : }
{ "_id" : "08d0d626-b37b-4761-81b2-98b5ee426df8", "la" : ISODate("2017-06-29T13:56:14.974Z"), "n" : }
{ "_id" : "6d2eef45-cb25-4ff6-b8cd-497ab3b938ae", "la" : ISODate("2017-07-07T02:19:16.154Z"), "n" : }
{ "_id" : "6f444a2b-e2fc-4ab0-8b1d-d4334bf095e3", "la" : ISODate("2017-07-09T12:17:05.711Z"), "n" : }
{ "_id" : "85e06ac1-7158-42fb-95ed-2cd39a7f0687", "la" : ISODate("2017-06-26T02:27:25.389Z"), "n" : }
Type "it" for more
> db.online_users55d2e563292d6b2c7d1d132d.find({"_id" : "4e5d3922-6553-430a-849f-8b1007373d7c"}).explain()
{
"cursor" : "BtreeCursor _id_",
"isMultiKey" : false,
"n" : ,
"nscannedObjects" : ,
"nscanned" : ,
"nscannedObjectsAllPlans" : ,
"nscannedAllPlans" : ,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : ,
"nChunkSkips" : ,
"millis" : ,
"indexBounds" : {
"start" : {
"_id" : "4e5d3922-6553-430a-849f-8b1007373d7c"
},
"end" : {
"_id" : "4e5d3922-6553-430a-849f-8b1007373d7c"
}
},
"server" : "localhost:27017"
}
明明是走索引的，可能是la这一列没有加索引（这个我当时没有看，但是从现在来看这个思路应该是正确的）
加上索引
db.online_users547c2a634dcc1eef3d000001.ensureIndex({la: }, {expireAfterSeconds: });
因为这个是cache性质频繁读写的表，要转成Capped Collection，自动老化移出，优化性能，并设置最大记录数
db.runCommand({"convertToCapped":"online_users547c2a634dcc1eef3d000001",size:})
db.runCommand({"convertToCapped":"live_data547c2a634dcc1eef3d000001",size:60})
这样之后结果就是好多了，再观察一段时间吧
记一次mogodb占用cpu高问题的更多相关文章
- 再记一次w3wp占用CPU过高的解决过程（Dictionary和线程安全）
在此之前项目有发生过两次类似的状况,都得以解决,但最近又会发现偶尔CPU会跑满,虽然之前使用过WinDbg解决过两次问题但人的记忆是不可靠的,今天处理同样问题的时候还是遇到了一些障碍,这一次希望可以记 ...
- 关于csrss.exe和winlogon.exe进程多、占用CPU高的解决办法，有人在暴力破解
关于csrss.exe和winlogon.exe进程多.占用CPU高的解决办法 最近VPS的CPU一直处在100%左右,后台管理上去经常打不开,后来发现上远程都要好半天才反映过来,看到任务管理器有多个 ...
- TortoiseSVN status cache占用CPU高
进程占用CPU高 每次从SVN上更新资源时,电脑都会卡死,直到资源更新完.当要Commit资源时,SVN也会卡死资源管理器,如下图所示: 解决占用CPU高的问题 1.禁用图标缓存 2.排除路径和包含路 ...
- 关于csrss.exe和winlogon.exe进程多、占用CPU高的解决办法
原地址 http://blog.sina.com.cn/s/blog_912e77480101nuif.html 最近VPS的CPU一直处在100%左右,后台管理上去经常打不开,后来发现上远程都要 ...
- 查看tomcat项目中，具体占用cpu高的线程。
1.查看主进程占用cpu高: 此处主进程:27823 ~]# top top - :0: up days, :, 3 users, load average: 13.12, 13.31, 13.23 ...
- 查看JAVA占用CPU高的线程日志
# . 查看主进程占用cpu高 top # java # . 按照线程占用cpu由高到低进行排查: -o THREAD,tid, # USER %CPU PRI SCNT WCHAN USER SYS ...
- linux c++应用程序内存高或者占用CPU高的解决方案_20161213
对于绝大多数实时程序来说,实时处理相关程序中的循环问题所带来的对机器的损耗和自身的处理速度的平衡,以及与其他程序的交互以及对其他功能的影响难免会成为程序设计中最大的障碍同时也是最大的突破点. 在所有这 ...
- 利用jstack命令定位占用cpu高的java线程及具体错误代码信息
1.先用top查询某进程的线程CPU占用情况,定位到cpu占用高的进程pid 2.根据pid定位具体的线程top -p PID -H ,找出占用cpu最大的pid,此处占用cpu比较平均,我们随便选择 ...
- 记一次w3wp占用CPU过高的解决过程（Dictionary和线程安全）
项目上线以来一直存在一个比较揪心的问题,和一个没有信心处理的BUG,那就是在应用程序启动时有可能会导致cpu跑满99%或持续在一个值如50%左右,这样一来对服务器的压力是非常大的,经常出现服务器无法远 ...
随机推荐
- 17.Delete Methods-官方文档摘录
介绍delete的方法 MongoDB provides the following methods to delete documents of a collection: db.collectio ...
- Linux下的内核抢占
2017-03-03 很遗憾之前在介绍进程调度的文章中,虽然涉及到了内核抢占,但是却没有对其进行深入介绍,今天就稍微总结下内核抢占. 内核抢占在一定程度上减少了对某种事件的响应延迟,这也是内核抢占被引 ...
- Django中间件如何处理请求
Django中间件 在http请求 到达视图函数之前 和视图函数return之后,django会根据自己的规则在合适的时机执行中间件中相应的方法. Django1.9版本以后中间件的执行流程 1. ...
- SDUT3165:Round Robina(循环链表）
题目:http://acm.sdut.edu.cn/sdutoj/problem.php?action=showproblem&problemid=3165 题意分析: 比赛时这题没有A真伤心 ...
- 前端须知的http header
文件信息: Content-Type: application/x-javascript Content-Length: 2000 Content-Type:指定请求和响应的内容类型,如果未指定即为t ...
- 取得选中Grid的数据
var MergeAction = new Ext.Action({ text: '合并(选中两行)', handler: function () { if (grid.getSelectionMod ...
- jQuery—$让渡
方法1:(取别名) 方法2:(指定作用域) 场景用例: 解决方案:方法1(取别名) 解决方案:方法2(指定作用域)
- POJ - 1511 - 两次SPFA
这道题也算是一道模板题,但是第一次用优先队列迪杰斯特拉就T了.1e6的数据量,给了8s,网上其他题解中说要用SPFA. 题意:N个点的带权有向图.每次都从1出发,要到达其余没有被访问过的一个点(发传单 ...
- 性能调优之MySQL篇三：MySQL配置定位以及优化
1.优化方式 一般的优化方法有:硬件优化,配置优化,sql优化,表结构优化.下面仅仅介绍配置优化,具体优化设置可以参考本人另外一篇博客,传送门:https://www.cnblogs.com/lang ...
- 【android】夜间模式简单实现
完整代码,请参考我的博客园客户端,git地址:http://git.oschina.net/yso/CNBlogs 关于阅读类的app,有个夜间模式真是太重要了. 那么有两种方式可以实现夜间模式 1: ...