DNS cpu 太高了
看到一篇帖子說DNS cpu 佔用率過高，看了回帖，發現我這個問題還是有不同的。
機器是雙cpu的
用dnstop查看的結果
Queries: 506 new, 17119 total Wed Jul 22 14:22:59 2009
Sources Count %
-------------- --------- ------
11.11.11.11 106 0.6
。。。。。。。。。
用top查看結果
top - 14:23:57 up 16 days, 1:16, 2 users, load average: 1.22, 1.21, 1.18
Tasks: 86 total, 2 running, 74 sleeping, 10 stopped, 0 zombie
Cpu(s): 19.3%us, 6.9%sy, 0.0%ni, 72.7%id, 0.0%wa, 0.0%hi, 1.1%si, 0.0%st
Mem: 4152048k total, 1289400k used, 2862648k free, 167848k buffers
Swap: 7815612k total, 0k used, 7815612k free, 901444k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8878 root 20 0 59336 55m 1896 R 94 1.4 51:30.14 named
8732 mysql 20 0 137m 28m 5036 S 11 0.7 9:07.63 mysqld
8975 root 20 0 2308 1088 856 R 0 0.0 0:00.01 top
這台機器是專用的DNS伺服器。
Named 進程cpu佔用率一直是90% 多
貼一下named.conf 配置文件
沒有開啟recursion 數據是從mysql資料庫 讀取的。
options {
pid-file "/var/run/named.pid";
allow-query { any; };
recursion no;
version "gaint-d1";
};
key "rndc-key" {
algorithm hmac-md5;
secret "xLTl+WTLNa/gF3djG4Q8Dw==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
logging {
channel query_log {
file "/var/log/query.log" versions 3 size 20m;
severity info;
print-time yes;
print-category yes;
};
category queries {
query_log;
};
};
include"/var/named/ipList.acl";
view "anhuidianxin" {
match-clients { anhuidianxin; };
dlz "Mysql zone" {
database "mysql
{host=127.0.0.1 dbname=xxx ssl=false port=3306 user=xxx pass=xxx}
{select p_value from domain_area_parse where zone='%zone%'}
{select ttl, p_type, mx_priority, case when lower(p_type)='txt' then concat('\"',p_value,'\"')
when lower(p_type)='soa' then concat_ws(' ',p_value,resp_person,serial,refresh,retry,expire,minimum) else p_value end as cdn from domain_area_parse where p_area=7 and p_state='1' and zone='%zone%' and p_domain_name='%record%'}";
};
};
[ 本帖最後由 aobai 於 2009-7-22 14:52 編輯 ]
《解決方案》
不知是LZ看錯了，還是我看錯了，CPU佔用20％多啊，何來90％。當然做為DNS伺服器這20％多主要是named進程佔用的這很正常啊。
Cpu(s): 19.3%us, 6.9%sy, 0.0%ni, 72.7%id, 0.0%wa, 0.0%hi, 1.1%si, 0.0%st
[ 本帖最後由 llzqq 於 2009-7-23 06:53 編輯 ]
《解決方案》
原帖由 llzqq 於 2009-7-23 06:50 發表 http://bbs2.chinaunix.net/images/common/back.gif
不知是LZ看錯了，還是我看錯了，CPU佔用20％多啊，何來90％。當然做為DNS伺服器這20％多主要是named進程佔用的這很正常啊。
Cpu(s): 19.3%us, 6.9%sy, 0.0%ni, 72.7%id, 0.0%wa, 0.0%hi, 1.1%si, 0.0%st
是我看錯了。 面壁思過
還可以優化不？
我覺得如果優化應該從MYSql 數據這個方向考慮
《解決方案》
原帖由 aobai 於 2009-7-23 09:25 發表 http://bbs2.chinaunix.net/images/common/back.gif
是我看錯了。 面壁思過
還可以優化不？
我覺得如果優化應該從MYSql 數據這個方向考慮
對於大併發量的DNS，如果採用的是BIND+DB的模式，要考慮採用DB集群模式。因為這裡DB是瓶頸。或者放棄讓BIND直接查詢DB這個模式。
《解決方案》
在ubuntu中運行 dnstop -l 4 eth0
Queries: 506 new, 17119 total Wed Jul 22 14:22:59 2009
Sources Count %
-------------- --------- ------
11.11.11.11 106 0.6
。。。。。。。。。
也就500左右。 這個並不大。
http://bind-dlz.sourceforge.net/perf_tests.html
上面網頁最後說mysql跑600多都 沒有問題，現在還沒有必要換資料庫。
如果以後大了就喊DB吧
今天聽人說自己在bind中改代碼，然後自己實現了一個我們dlz 模塊的功能（他說是查詢資料庫）， 據說能夠併發上萬 ，不可思議。。 為什麼不用dlz呢？ dlz 處理上萬的應該也不是問題丫 。。
如果放棄bind+資料庫 模式， 難道自己讀配置文件？
還有其他的模式沒有？
[ 本帖最後由 aobai 於 2009-7-24 16:06 編輯 ]
《解決方案》
如果量大，DB的查詢是很大的瓶頸，我們採取的方法是用資料庫管理用戶、配置文件和zone文件，通過程序將資料庫寫入文件由bind讀取，畢竟dns修改頻率不高，而且生效又無需實時，這樣足夠了，沒必要在每台伺服器上都運行資料庫，這樣也減少了負載，增加了安全性
《解決方案》
原帖由 kor 於 2009-7-28 10:40 發表 http://bbs2.chinaunix.net/images/common/back.gif
如果量大，DB的查詢是很大的瓶頸，我們採取的方法是用資料庫管理用戶、配置文件和zone文件，通過程序將資料庫寫入文件由bind讀取，畢竟dns修改頻率不高，而且生效又無需實時，這樣足夠了，沒必要在每台伺服器上 ...
不知道我的理解對不？
你的意思是這樣
首先用資料庫管理相關的文件和數據
然後在資料庫中查詢相關的欄位，生成我們一般的配置文件（不用dlz)
因為DNs 改變不大，所有這樣做也是可行的。。
這樣就牽涉到一個問題？
dlz到底有什麼優勢？
除了用資料庫管理方便，能夠不用重啟就更新，還有什麼更加突出的優勢?
其實我們以前是用腳本實現了一個這樣的功能的， 為的是使用dlz的bind出問題后我們能夠很快的切換到不使用dlz的模式。
