redmine在linux上的mysql性能優化方法與問題排查方案

iredmine的linux服務器mysql性能優化方法與問題排查方案
 
 
問題定位:
 
客戶端工具:
1. 瀏覽器inspect-tool的network timing工具分析
 
2. 瀏覽器查看 response header, 分析http server 與 web server.
 
 
 
服務器工具:
 
0. nmon 查看各種系統負載, rrdtool 查看網絡情況。
 
1. uptime看cpu負載;    free看內存;  mem ; cat /proc/meminfo以及  iostat(sysstat)看IO / iotop看個體IO; sar dstat看全局。
 
 
2. pidstat -d -p 1234 1 1000  ; -d 用於查看IO, -r用於report page faults,-u用於查看cpu;  -p 指定監控的進程 ,最後的數字是 interval 和 counts
 
 
3. iostat -d -x -k 1 10      #查看設備使用率(%util)、響應時間(await)
 
命令: iostat -m -x 1 1000  能夠觀察對應的CPU中的%iowait數據,除此以外iostat還提供了一些更詳細的I/O狀態數據,好比比較重要的有: 
avgqu-sz :  The average queue length of the requests that were issued to the device. (磁盤隊列的請求長度,正常的話2,3比較好。能夠和cpu的load同樣的理解)
await : The average time (in milliseconds) for I/O requests issued to the device to be served. (表明一個I/O操做從wait到完成的總時間)
svctm和%util都是表明處理該I/O請求花費的時間和CPU的時間比例。 判斷是否瓶頸時,這兩個參數不是主要的
 
r/s w/s 和 rMB/s  wMB/s 都是表明當前系統處理的I/O的一些狀態,前者是咱們常說的tps,後者就是吞吐量。這也是評價一個系統的性能指標
 
 
4. iotop -p xxx -n 100 -d 3    # 查看特定pid的 io, 並指定-d 延遲 和 -n 刷新次數
 
 
 
5. dstat --disk --mem --proc --io --sys --filesystem --tcp --vm --output dstat.csv   將各項數據信息統計,並寫入 dstat.csv中。
    1. 更方便的: ./dstat_mysql_io.sh  -t  -df  --disk-util --disk --mem --proc --top-cpu  --top-latency  --top-bio --io --sys --filesystem --tcp --vm --output dstat.csv
    能夠直接查看-t: 當前時間, top block io 和 top cpu ,以及 top latency的程序,對分析IO瓶頸 cpu負載  各個硬盤的讀寫 很是方便。 
 
    2. dstat --mysql-io 利用/usr/share/dstat中的python擴展腳本,能夠經過driver查看mysql的io狀態,前提是須要安裝python-mysqldb的接口。
    3. dstat : dstat -cmsdnl -D sda > dstat_test.log  能夠指定某個磁盤的狀態。
    4. 命令:dstat -y --tcp 1 1000  經過dstat --tcp能夠比較方便的看到當前的tcp的各類狀態,不須要每次netstat -nat去看。
 
 
6. sar命令監控全設備指標, 如 -u表明cpu, -b表明IO,  -r 表明內存和交換空間,還能夠自動將數據保存下來 -o:保存到指定文件名,-f:加載指定文件數據, 最後,還有兩個參數分別表示 interval 和 count,  如: sar -b -o sarIO.log 1 100 . 意思就是每秒1次的頻率循環100次 監控IO數據 並保存到sarIO.log文件中。
 
7. 觀察系統部件10分鐘,並對數據進行排序: sar -o temp 60 10
 
 
8. 如何肯定swap分區與mysql DB data 在同一個磁盤上? 若是在同一個磁盤會產生swap 時 與 mysql 爭搶 磁盤IO.
 
 
9. iostat 與 iotop 、 dstat、sar 分別統計的是哪個層級的IO數據? linux系統io原理是如何? cache原理是如何?
 
 
10. top在多核系統中 cpu% 是如何計算的?mysql是否能夠設置使用多核運行? 仍是隻能運行在單核?
命令:線程跟蹤: top -Hp pid  能夠實時的跟蹤並獲取指定進程中最耗cpu的線程。 再用前面的方法提取到對應的線程堆棧信息。
    iotop 中的TID 也是指線程。
 
 
11. pidstat -p pid -u -d -t -w -h 1 1000  至關實用的一個命令,能夠基於當個進程分析對應的性能數據,包括CPU,I/O,IR , CS等,能夠方便開發者更加精細化的觀察系統的運行狀態。不過pidstat貌似是在2.6內核的一些較新的版本纔有,須要安裝sysstat包。
ubuntu下,能夠經過sudo apt-get install sysstat進行安裝。
 
 
12. mpstat -P ALL 1 1000  查看顯示各cpu的使用情況,iowait與 user /sys 結合能夠分析出。
注意一下這裏面的%iowait列,CPU等待I/O操做所花費的時間。這個值持續很高一般多是I/O瓶頸所致使的。
經過這個參數能夠比較直觀的看出當前的I/O操做是否存在瓶頸
 
 
13. netstat -nltp 查看端口連接以及對應進程信息
 
 
14. lsof -i: 80  能夠查看指定端口占用進程。
      lsof -p pid 能夠查看指定pid的進程佔用的資源。
 
 
15. atop 監視系統cpu  irq 和 IO子系統, 並能夠提供週期性採集並保存數據稱日誌供之後分析。
 This isn't strictly answering your question, but you might find atop more useful. It can run as a daemon and write to a binary log file. The file contains all data necessary to reproduce what would have been seen had atop been run 'live'.
 
To run atop as a daemon, you could kick it off as
 
/usr/bin/atop -a -w /var/log/atop.log 60
 
to write a snapshot to the log every 60 seconds. Later you can see what was going on at a specific time by doing e.g.
 
atop -r /var/log/atop.log -b 10:00
 
to start at 10am. You can then step backwards and forwards throught the log to see how system activity developed.
 
To address your specific question of disk activity, pressing d while in atop will sort processes by their total disk activity at that point in time, and in the summary at the top of the screen you'll be able to see aggregated per-device statistics.
 
 
 
 
16. mysql 數據庫大小  #查看數據庫的大小,單位MByte 
 
root@iRedmine:/redmine/mysql/bin# ./mysql -uroot -p1111 -e 'select table_schema,round(sum(data_length+index_length)/1024/1024,1) from information_schema.tables group by table_schema;'
+--------------------+--------------------------------------------------+
| table_schema       | round(sum(data_length+index_length)/1024/1024,1) |
+--------------------+--------------------------------------------------+
| bitnami_redmine    |                                            563.6 |
| information_schema |                                              0.0 |
| mysql              |                                              0.6 |
| performance_schema |                                              0.0 |
+--------------------+--------------------------------------------------+
 
17. mysql數據庫的基本狀態 mysqladmin status
./mysqladmin -uroot -p1111 status
 
18. mysql數據庫的詳細狀態 mysqladmin extended-status
./mysqladmin -uroot -p1111 status
 
 
19. mysql有一個有名的tuning-primer.sh
 
20. mycheckpoint 工具
     下載:  wget https://mycheckpoint.googlecode.com/files/mycheckpoint-231.tar.gz
     使用方法以下:
     1. 建立表 create database mycheckpoint;
     2. 受權
          GRANT ALL PRIVILEGES ON mycheckpoint.* TO 'root'@'localhost' IDENTIFIED BY '1111';
     3. 初始化
          mycheckpoint --host=127.0.0.1 --port=3306 --user=root --password=1111 --socket=/redmine/mysql/tmp/mysql.sock --database=mycheckpoint
 
     4. 啓動http服務器查看
          mycheckpoint --host=127.0.0.1 --port=3306 --user=root --password=1111 --socket=/redmine/mysql/tmp/mysql.sock --database=mycheckpoint http
 
          * * * * * /usr/local/bin/mycheckpoint  --user=root --password=1111 --socket=/redmine/mysql/tmp/mysql.sock --database=mycheckpoint
 
 
 
21. percona-toolkit 工具
      1. ./pt-index-usage --socket /redmine/mysql/tmp/mysql.sock --user root --password 1111
 
 
 
22. 如何開啓慢查詢自動Log功能,以及如何分析慢查詢?  使用percona-toolkit  
     1.方法一: 修改 my.conf
     2. 在mysql控制檯使用 set variable 
 
23. 監視影響 MySQL 性能的主要指標。如查詢緩存命中率,Key_buffer_read_hits,Key_buffer_write_hits,Thread_cache_hits,Key_blocks_used_rate,Created_tmp_disk_tables_rate等信息,根據相關性能指標能夠對服務器核心參數進行調整優化。
 
 
24. 磁盤工具: du -chd 1  表示只看當前目錄下深度爲1 的各個文件夾的大小。
 
 
25. 使用mysqltuner.pl進行狀態監測與 性能調優建議。
   1. wget http://mysqltuner.pl/ -O mysqltuner.pl
   2. perl mysqltuner.pl
   在運行iredmine服務器上面運行後,  得到以下建議:
root@iRedmine:~/performanceLog# export PATH=$PATH:/redmine/mysql/bin/
root@iRedmine:~/performanceLog# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/redmine/mysql/bin/
root@iRedmine:~/performanceLog# perl mysqltuner.pl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
     LANGUAGE = "en_US:en",
     LC_ALL = (unset),
     LC_PAPER = "zh_CN.UTF-8",
     LC_ADDRESS = "zh_CN.UTF-8",
     LC_MONETARY = "zh_CN.UTF-8",
     LC_NUMERIC = "zh_CN.UTF-8",
     LC_TELEPHONE = "zh_CN.UTF-8",
     LC_IDENTIFICATION = "zh_CN.UTF-8",
     LC_MEASUREMENT = "zh_CN.UTF-8",
     LC_TIME = "zh_CN.UTF-8",
     LC_NAME = "zh_CN.UTF-8",
     LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
 
>>  MySQLTuner 1.4.0 - Major Hayden <major@mhtx.net>
>>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
>>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:
[OK] Currently running supported MySQL version 5.5.32
[OK] Operating on 64-bit architecture
 
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in InnoDB tables: 371M (Tables: 92)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 92
 
-------- Security Recommendations  -------------------------------------------
[!!] User '@localhost' has no password set.
[!!] User '@ubuntu-12' has no password set.
 
-------- Performance Metrics -------------------------------------------------
[--] Up for: 8d 8h 26m 44s (59M q [81.922 qps], 4K conn, TX: 185B, RX: 11B)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 168.0M global + 2.8M per thread (151 max threads)
[OK] Maximum possible memory usage: 583.2M (0% of installed RAM)
[OK] Slow queries: 0% (396/59M)
[OK] Highest usage of available connections: 9% (15/151)
[OK] Key buffer size / total MyISAM indexes: 8.0M/102.0K
[OK] Key buffer hit rate: 100.0% (112M cached / 89 reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (1K temp sorts / 3M sorts)
[!!] Joins performed without indexes: 2484
[!!] Temporary tables created on disk: 39% (1M on disk / 4M total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 3% (404 open / 12K opened)
[OK] Open file limit used: 6% (71/1K)
[OK] Table locks acquired immediately: 99% (92M immediate / 92M locks)
[!!] InnoDB  buffer pool / data size: 128.0M/371.4M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
Variables to adjust:
    query_cache_size (>= 8M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_open_cache (> 800)
    innodb_buffer_pool_size (>= 371M)
 
另外還有: thread_concurrency = 32;  (cpu*2)
 
26. mysql 針對請求的執行邏輯,影響到性能的關鍵指標: 
 
 
參考: http://files.cnblogs.com/files/ToDoToTry/mysqlio-120511033204-phpapp02.pptx
參考: 系統各組件的吞吐量, http://blog.yufeng.info/archives/category/linux_kb/page/13
參考: 數據庫訪問性能優化法則: http://blog.csdn.net/yzsind/article/details/6059209
 
 
27. wget 的使用
1. 保存cookie: --save-cookies filename
   wget --save-cookies cookies.txt \
     --post-data 'user=foo&password=bar' \
     http://server.com/auth.php
2. 使用cookie :  --load-cookies  filename
wget --load-cookies=cookie -p   http://localhost:8080/issues/48575  
 
3. 保存結果到指定文件: -O filename
wget   http://localhost:8080/issues/48575    -O foo.html
 
4. 登錄post User password
# Log in to the server.  This can be done only once.
   wget --save-cookies cookies.txt   --post-data 'user=foo&password=bar'   http://server.com/auth.php
5. 包含hidden位的wget登錄腳本:
 
#!/bin/sh
# get the login page to get the hidden field data
wget -a log.txt -O loginpage.html http://foobar/default.aspx
hiddendata=`grep value < loginpage.html | grep foobarhidden | tr '=' ' ' | awk '{print $9}' | sed s/\"//g`
rm loginpage.html
 
# login into the page and save the cookies
postData=user=fakeuser'&'pw=password'&'foobarhidden=${hiddendata}
wget -a log.txt -O /dev/null --post-data ${postData} --keep-session-cookies --save-cookies cookies.txt http://foobar/default.aspx
 
# get the page your after
wget -a log.txt -O results.html --load-cookies cookies.txt http://foobar/lister.aspx?id=42
rm cookies.txt
 
 
 
28. ab測試:
1.指定header
ab -n 100 -H "Cookie: Key1=Value1; Key2=Value2"    http://localhost:8080/issues/48575
 
2.指定cookie
ab -n 10000  -c 50 -g n10k_50c   -C '_redmine_session="e66011c9"'   http://localhost:8080/issues/48575
 
3.
 
 
29. http_load
 
 
 
30. webbench
 
 
 
 
31. siege  url 
 
 
 
32. curl_loader
 
 
 
ab測試時,即便使用了cookie來假裝已登錄用戶,也老是被iredmine服務器開啓了csrf拒絕服務,轉向到login頁面,解決方法:
1.找到redmine發佈的代碼中controller目錄下的ApplicationController.rb文件,將其中的csrf保護函數protect_from_forgery中cookie.delete(auto_cookie_name)行註釋掉。代碼以下:
 
class ApplicationController < ActionController::Base
  include Redmine::I18n
  include Redmine::Pagination
  include RoutesHelper
  helper :routes
 
  class_attribute :accept_api_auth_actions
  class_attribute :accept_rss_auth_actions
  class_attribute :model_object
 
  layout 'base'
 
  protect_from_forgery
  def handle_unverified_request
    super
    #cookies.delete(autologin_cookie_name)
  end
 
  before_filter :session_expiration, :user_setup, :check_if_login_required, :set_localization
 
  rescue_from ActionController::InvalidAuthenticityToken, :with => :invalid_authenticity_token
  rescue_from ::Unauthorized, :with => :deny_access
  rescue_from ::ActionView::MissingTemplate, :with => :missing_template
 
  include Redmine::Search::Controller
  include Redmine::MenuManager::MenuController
  helper Redmine::MenuManager::MenuHelper
 
  def session_expiration
    if session[:user_id]
      if session_expired? && !try_to_autologin
        reset_session
        flash[:error] = l(:error_session_expired)
        redirect_to signin_url
      else
        #session[:atime] = Time.now.utc.to_i
      end
    end
  end
 
33. passenger的配置放在了apache2.conf文件中:
      1. Passenge# PassengerMaxPoolSize
# Default: 6
# For 2gb RAM: 30
# For 256 slice with MySQL running: 2
PassengerMaxPoolSize 2
 
# PassengerPoolIdleTime
# Recommended to be avg time per page * 2
# In Google Analytics... (Avg time on site / Avg page views) * 2
# Default: 300
PassengerPoolIdleTime 150
MaxPoolSize 2
 
RAM (MB) PassengerMaxPoolSize
256 2
512 6 (default)
1024 (1GB) 15
2048 (2GB) 30
 
 
34. puma 安裝
    mysql2 C語言擴展: export JRUBY_OPTS="--1.9 -Xcext.enabled=true"
    puma的多workers 多threads 的啓動  
    puma -w 4 -t 32 -p 8080  -e production  /redmine/apps/redmine/htdocs/config.ru
 
35.  innodb的memcached plugin, 與 mysql + native memcached 配置,使用,coding時的要點。
 
 
36. mysql讀寫分離 設計方案, coding方案
 
 
37.  orztop 查看mysql實時當前運行的sql語句的工具, 須要安裝perl庫依賴: readkey。
安裝依賴: sudo apt-get install libdbi-perl
sudo apt-get install libdbd-mysql-perl
sudo apt-get install libterm-readkey-perl
或者經過cpan下載安裝須要的安裝perl庫依賴: readkey。
 
38. 分析查看當前運行的sql語句: show processlist/show full processlist抓取sql
 
 
39. orzdba 查看全部mysql性能信息:svn co http://code.taobao.org/svn/orzdba/trunk 
 
40. 如何預估mysql在產品環境下的性能?:
1. 使用orztop| tee currentSQL.log 來記錄下一個url請求對應的sql語句
2. 找到currentSQL.log中記錄下的sql語句,這些都是實際請求中執行的sql, 複製一下。
3. 將上一步複製的sql語句貼入到phpmyadmin當中執行,勾選profiling。
4. 觀察結果,能夠看到上述sql語句的精確耗時。 再用1s去除以耗時。
5. 同時,若是打開了open-table等較大,cache命中率較高,實際環境中可能比試驗環境更高的性能。
 
41. 肯定mysql的IO操做究竟在PageIO,仍是sync 到文件IO, 多少次。 操做了哪一個文件,是lseek隨機操做 ,仍是順序操做。
 
 
42. 經過log目錄下的production.log能夠看到每次請求中,render頁面 和 active-record分別佔用了多長時間。
因爲rails默認開啓了rack, Rails::Rack::Logger, 會將http訪問的 頁面渲染Render 和 active-record耗時記錄下來,若是是develop模式記錄的東西更多,甚至包括sql語句都會打印出來,這將會極度地拖慢服務器效率。 因此,讓puma或者passenger以production模式運行,並關閉Rails::Rack::Logger , rack::timer會提高不少性能。
 
43.如何關閉rails的middleware,
1. 使用rack middleware 查看當前使用的middleware,
2. 在如下文件中添加代碼,手動刪除不須要的,或者是對性能損耗大的middleware。
# config/application.rb
config.middleware.delete "Rack::MethodOverride"
 
44. 如何讓puma以production模式運行服務器?
1. puma -w 4 -t 6 -p 8088 -e production  /redmine/apps/redmine/htdocs/config.ru
2. 
 
45. 如何關閉logger
 
 
46. 3.2.13版的rails的log中能夠看到render頁面耗時很是高,以下:
Rendered issues/show.html.erb within layouts/base (301.4ms)
Completed 200 OK in 557ms (Views: 336.7ms | ActiveRecord: 62.1ms)
緣由:
1. 開啓了assets.debug
2. 開啓了assets.raise_runtime_errors 
3. 3.2.13版的bug
解決辦法:
1. 
You can leave config.assets.debug = true but should disable new assets verification feature
 
# Adds additional error checking when serving assets at runtime.
# Checks for improperly declared sprockets dependencies.
# Raises helpful error messages.
config.assets.raise_runtime_errors = false
Solution with config.assets.debug disabled only works because it compiles assets once and assets are verified once. Assets verification is where the most of the time is spent.
 
2.
If you're coming from rails 3.2.13 note that a bunch of people have experienced this issue and reverting to 3.2.12 seems to resolve it. You can find more info here on github.
 
In my case disabling config.assets.debug sped things up a little, but reverting to 3.2.12 dropped request time from around 4 seconds to around 250ms.
 
 
進過再次考察,發現rails的Render速度就是這個數量級的,確實須要200ms左右。 媽蛋!
 
47. oprofile 很是強大的工具,1. 查看系統使用,2. 查看特定進程中各個函數使用率。
 
 
48. Gprof 是 Linux 下一個強有力的程序分析工具。對於 C 、 Pascal 或者 Fortran77 語言的程序,它可以以「 日誌」的形式記錄程序運行時的統計信息:程序運行中各個函數消耗的時間和函數調用關係,以及每一個函數被調用的次數等 , 還能夠顯示「註釋的源代碼」,是程序源代碼的一個複本,標記有程序中每行代碼的執行次數。 
程序分析是以某種語言書寫的程序爲對象,對其內部的運做流程進行分析。
gpro f 是 gnu binutils 工具之一,默認狀況下 linux 系統當中都帶有這個工具。
使用 -pg 選項來編譯 hello.c ,若是要獲得帶註釋的源碼清單,則須要增長 -g 選項。運行:
gcc -pg -g -o hello hello.c
運行應用程序: ./hello 會在當前目錄下產生 gmon.out 文件
使用 gprof 來分析 gmon.out 文件,須要把它和產生它的應用程序關聯起來:
gprof hello gmon.out -p 獲得每一個函數佔用的執行時間
gprof hello gmon.out -q 獲得 call graph ,包含了每一個函數的調用關係,調用次數,執行時間等信息。
gprof hello gmon.out -A 獲得一個帶註釋的「源代碼清單」,它會註釋源碼,指出每一個函數的執行次數。這須要在編譯的時候 增長 -g 選項。
用 gprof 程序分析應用程序生成的數據時:若是內容太多,一屏顯示不過來,能夠經過 more/less 來分屏顯示。 
gprof -b hello gmon.out | less
 
49. zoom是一個相似與oprofile 可是提供了相似mac osx 上shark的GUI界面。
 
 
50. 阿里巴巴的myrelay 是一個優秀的 mysql 異步代理, 事件驅動,非阻塞。
mysql的代理,支持以下特性:
採用事件驅動、異步、非阻塞的設計模式,性能優秀
採用mysql原生協議,對應用層透明
支持mysql讀寫分離
提供mysql鏈接池管理
支持mysql冗餘、健康檢查
提供mysql的查詢日誌,方便對應用層進行分析
支持mysql配置動態加載
C語言實現
2、 應用場景
Mysql數據庫集羣訪問,負載均衡、冗餘、健康檢查等
Mysql讀寫分離
3、 性能
優秀。通常應用經過代理訪問數據庫的性能將達到直連數據庫性能的95%
4、 安裝
經過svn下載源碼
編譯庫文件
cd oplib/src/ && make install
編譯程序
make install
建立目錄
mkdir -p /home/admin/myrelay
mkdir -p /home/admin/myrelay/bin
mkdir -p /home/admin/myrelay/conf
mkdir -p /home/admin/myrelay/lib
cp myrelay /home/admin/myrelay/bin
cp conf/* /home/admin/myrelay/conf/
cp oplib/lib/oplib.so /home/admi/myrelay/lib/
5、 執行
配置LD_LIBRARY_PATH環境變量,讓程序可以找到庫文件
例如: export LD_LIBRARY_PATH="/home/admin/myrelay/lib"
執行程序
cd /home/admin/myrelay/bin && ./myrelay ../conf/myrelay.conf
 
 
51. 指標收集: collectd
 
 
52.指標收集: statsd(statsite)
 
 
53. 指標繪圖 graphite
 
 
54. 監控、報警自動化: nagios / cacti /ganglia、zabbix
1. nagios,優點:報警的及時性和web界面的顯示 
劣勢:配置相對比較繁瑣,無web界面管理添加主機,數據無存檔 
2. cacti,優點:以snmp爲主要取數工具,取得數據後存入rra文件 以rrdtools展示監控數據,相對添加主機和性能趨勢分析有比較大優點 
劣勢:報警的及時性有所欠缺 
3. zabbix,優點:分佈式服務器監控,能夠對多機房統一監控,一個局域網配置一臺proxy代理主機收集數據彙總給監控主機,支持snmp zabbix_agentd等多種方式監控,對自定義數據收集比cacti腳本簡單,有設備報備功能等等,功能十分強大適合大型分佈式架構 
劣勢:相對來講佔用資源較高,數據以mysql數據庫存儲爲主,graph顯示較慢(多是由於數據量太大,沒有cacti那麼流暢)
 
 
55. 配置部署自動化: puppet(收費)、salt(python,免費)、 ansible
 
56. 系統安裝自動化: kickstart(鳥哥教程、pxe/安裝系統/ Windows Deployment Services) /cobbler/
 
 
58. 具有網絡監控和資產管理,zabbix開源解決方案最合適不過了。比較完整的監控項,可定製化較強。導入導出監控配置模版,上手了就離不開它。
涉及運維自動化的話有:
1 系統安裝自動化:kickstart,cobbler等
2 配置部署自動化:puppet,saltstack,ansible等
3 監控自動化 nagios,ganglia,cacti等
以上都是開源運維經常使用工具。像bat的sa們都本身開發定製運維繫統了。
 
系統監控是做爲網站運維、網站性能優化必不可少的工具,目前比較經常使用的有Nagios、Cacti以及Zabbix,筆者用事後兩個,其中Zabbix確實很強大,web界面操做也比較不錯。不過這幾個工具安裝起來那可並不簡單,其中Nagios的複雜那但是出了名的。
 
 
59. 我比較看好zabbix這款監控軟件,理由以下:
1.分佈式監控,天生具備的功能,適合於構建分佈式監控系統,具備node,proxy2種分佈式模式
2.自動化功能,自動發現,自動註冊主機,自動添加模板,自動添加分組,是天生的自動化運維利器的首選,固然於自動化運維工具搭配,puppet+zabbix,或者saltstack+zabbix,那是如魚得水。
3.自定義監控比較方便,自定義監控項很是簡單,支持變量,支持low level discovery,能夠參考我寫的文檔自動化運維之監控篇---利用zabbix自動發現功能實現批量web url監控
4.觸發器,也就是報警條件有多重判斷機制,固然,這個須要你去研究一下,這也是zabbix的精華之處,
5.支持多種監控方式,agentd,snmp,ipmi,jmx,邏輯圖以下
 

 
 
60. mysql benchmark performance test .: 
 1.  mysql cluster能夠用: flexAsynch
 2. MySQLTuner 
 3. tuning-primer
 4. mycheckpoint
相關文章
相關標籤/搜索