如何使伺服器佔用過大

㈠ 怎樣處理伺服器負載量過大

第一，確認伺服器硬體是否足夠支持當前的流跡好茄量。 第二，優化資料庫訪問。 伺服器的負載過大，一個重要的原因是CPU負荷過大，降低伺服器CPU的負荷，才能夠有效打破瓶頸。而使用靜態頁面可以使得CPU的負荷最小化。前台實現完全的靜態化當然最好，可以完全不用訪問資料庫，不過對於頻繁更新的網站，姿察靜態化往往不能滿足某些功能。 緩存技術就是另一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問資料庫，WordPress和Z-Blog都大量使用這種緩存技術。我自己也寫過一個Z-Blog的計數器插件，也是基於這樣的原理。 如果確實無法避免對資料庫的訪問，那麼可以嘗試優化資料庫的查詢SQL.避免使用Select *from這樣的語句，每次查詢只返回自己需要的結果，避免短時間內的大量SQL查詢。 第三，禁止外部的盜鏈。 外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴格限制外部對於自身的圖片或者文件盜鏈，好在目前可以簡單地通過refer來控制盜鏈，Apache自己就可以通過配襪閉置來禁止盜鏈，IIS也有一些第三方的ISAPI可以實現同樣的功能。當然，偽造refer也可以通過代碼來實現盜鏈，不過目前蓄意偽造refer盜鏈的還不多，可以先不去考慮，或者使用非技術手段來解決，比如在圖片上增加水印。 第四，控制大文件的下載。 大文件的下載會佔用很大的流量，並且對於非SCSI硬碟來說，大量文件下載會消耗CPU，使得網站響應能力下降。因此，盡量不要提供超過2M的大文件下載，如果需要提供，建議將大文件放在另外一台伺服器上。

㈡ mariadb 如何實現伺服器內存使用最大化

查詢最高內存佔用

使用以下命令可以知道mysql的配置使用多少 RAM

SELECT ( @@key_buffer_size
+ @@query_cache_size
+ @@innodb_buffer_pool_size
+ @@innodb_additional_mem_pool_size
+ @@innodb_log_buffer_size
+ @@max_connections * ( @@read_buffer_size
+ @@read_rnd_buffer_size
+ @@sort_buffer_size
+ @@join_buffer_size
+ @@binlog_cache_size
+ @@thread_stack
+ @@tmp_table_size
)
) / (1024 * 1024 * 1024) AS MAX_MEMORY_GB;

可以使用mysql計算器來計算內存使用

下面是理論，可以直接到推薦配置

如何調整配置

key_buffer_size（MyISAM索引用）

指定索引緩沖區的大小，它決定索引處理的速度，尤其是索引讀的速度。為了最小化磁碟的 I/O ， MyISAM 存儲引擎的表使用鍵高速緩存來緩存索引，這個鍵高速緩存的大小則通過 key-buffer-size 參數來設置。如果應用系統中使用的表以 MyISAM 存儲引擎為主，則應該適當增加該參數的值，以便盡可能的緩存索引，提高訪問的速度。

怎麼設

show global status like 'key_read%';

+------------------------+-------------+
| Variable_name | Value |
+------------------------+-------------+
| Key_read_requests | 27813678764 |
| Key_reads | 6798830 |
---------------------

• key_buffer_size通過檢查狀態值Key_read_requests和Key_reads，可以知道key_buffer_size設置是否合理。

• 比例key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好。

• show global status like '%created_tmp_disk_tables%';



• key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表，但是內部的臨時磁碟表是MyISAM表，也要使用該值。可以使用檢查狀態值created_tmp_disk_tables得知詳情。

• 對於1G內存的機器，如果不使用MyISAM表，推薦值是16M（8-64M）

另一個參考如下

• show global status like 'key_blocks_u%';


• +------------------------+-------------+


• | Variable_name | Value |


• +------------------------+-------------+


• | Key_blocks_unused | 0 |


• | Key_blocks_used | 413543 |


• +------------------------+-------------+



Key_blocks_unused表示未使用的緩存簇(blocks)數，Key_blocks_used表示曾經用到的最大的blocks數，比如這台伺服器，所有的緩存都用到了，要麼增加key_buffer_size，要麼就是過渡索引了，把緩存占滿了。比較理想的設置：

• 可以根據此工式來動態的調整Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%

• show engines;



• 查詢存儲引擎

innodb_buffer_pool_size （innodb索引用）

這個參數和MyISAM的key_buffer_size有相似之處，但也是有差別的。這個參數主要緩存innodb表的索引，數據，插入數據時的緩沖。為Innodb加速優化首要參數。

該參數分配內存的原則：這個參數默認分配只有8M，可以說是非常小的一個值。

• 如果是專用的DB伺服器，且以InnoDB引擎為主的場景，通常可設置物理內存的50%，這個參數不能動態更改，所以分配需多考慮。分配過大，會使Swap佔用過多，致使Mysql的查詢特慢。

• 如果是非專用DB伺服器，可以先嘗試設置成內存的1/4，如果有問題再調整

query_cache_size（查詢緩存）

緩存機制簡單的說就是緩存sql文本及查詢結果，如果運行相同的sql，伺服器直接從緩存中取到結果，而不需要再去解析和執行sql。如果表更改了，那麼使用這個表的所有緩沖查詢將不再有效，查詢緩存值的相關條目被清空。更改指的是表中任何數據或是結構的改變，包括INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改變了的表的使用MERGE表的查詢。顯然，這對於頻繁更新的表，查詢緩存是不適合的，而對於一些不常改變數據且有大量相同sql查詢的表，查詢緩存會節約很大的性能。

• 注意：如果你查詢的表更新比較頻繁，而且很少有相同的查詢，最好不要使用查詢緩存。因為這樣會消耗很大的系統性能還沒有任何的效果

要不要打開？

先設置成這樣跑一段時間

• query_cache_size=128M


• query_cache_type=1



看看命中結果來進行進一步的判斷

• mysql> show status like '%Qcache%';


• +-------------------------+-----------+


• | Variable_name | Value |


• +-------------------------+-----------+


• | Qcache_free_blocks | 669 |


• | Qcache_free_memory | 132519160 |


• | Qcache_hits | 1158 |


• | Qcache_inserts | 284824 |


• | Qcache_lowmem_prunes | 2741 |


• | Qcache_not_cached | 1755767 |


• | Qcache_queries_in_cache | 579 |


• | Qcache_total_blocks | 1853 |


• +-------------------------+-----------+8 rows in set (0.00 sec)



Qcache_free_blocks:表示查詢緩存中目前還有多少剩餘的blocks，如果該值顯示較大，則說明查詢緩存中的內存碎片過多了，可能在一定的時間進行整理。

Qcache_free_memory:查詢緩存的內存大小，通過這個參數可以很清晰的知道當前系統的查詢內存是否夠用，是多了，還是不夠用，DBA可以根據實際情況做出調整。

Qcache_hits:表示有多少次命中緩存。我們主要可以通過該值來驗證我們的查詢緩存的效果。數字越大，緩存效果越理想。

Qcache_inserts: 表示多少次未命中然後插入，意思是新來的SQL請求在緩存中未找到，不得不執行查詢處理，執行查詢處理後把結果insert到查詢緩存中。這樣的情況的次數，次數越多，表示查詢緩存應用到的比較少，效果也就不理想。當然系統剛啟動後，查詢緩存是空的，這很正常。

Qcache_lowmem_prunes:該參數記錄有多少條查詢因為內存不足而被移除出查詢緩存。通過這個值，用戶可以適當的調整緩存大小。

Qcache_not_cached: 表示因為query_cache_type的設置而沒有被緩存的查詢數量。

Qcache_queries_in_cache:當前緩存中緩存的查詢數量。

Qcache_total_blocks:當前緩存的block數量。

• 我們可以看到現網命中1158，未緩存的有1755767次，說明我們這個系統命中的太少了，表變動比較多，不什麼開啟這個功能涉及參數

• query_cache_limit：允許 Cache 的單條 Query 結果集的最大容量，默認是1MB，超過此參數設置的 Query 結果集將不會被 Cache

• query_cache_min_res_unit：設置 Query Cache 中每次分配內存的最小空間大小，也就是每個 Query 的 Cache 最小佔用的內存空間大小

• query_cache_size：設置 Query Cache 所使用的內存大小，默認值為0，大小必須是1024的整數倍，如果不是整數倍，MySQL 會自動調整降低最小量以達到1024的倍數

• query_cache_type：控制 Query Cache 功能的開關，可以設置為0(OFF),1(ON)和2(DEMAND)三種，意義分別如下： 0(OFF)：關閉 Query Cache 功能，任何情況下都不會使用 Query Cache 1(ON)：開啟 Query Cache 功能，但是當 SELECT 語句中使用的 SQL_NO_CACHE 提示後，將不使用Query Cache 2(DEMAND)：開啟 Query Cache 功能，但是只有當 SELECT 語句中使用了 SQL_CACHE 提示後，才使用 Query Cache

• query_cache_wlock_invalidate：控制當有寫鎖定發生在表上的時刻是否先失效該表相關的 Query Cache，如果設置為 1(TRUE)，則在寫鎖定的同時將失效該表相關的所有 Query Cache，如果設置為0(FALSE)則在鎖定時刻仍然允許讀取該表相關的 Query Cache。

innodb_additional_mem_pool_size（InnoDB內部目錄大小）

InnoDB 字典信息緩存主要用來存放 InnoDB 存儲引擎的字典信息以及一些 internal 的共享數據結構信息，也就是存放Innodb的內部目錄，所以其大小也與系統中所使用的 InnoDB 存儲引擎表的數量有較大關系。

這個值不用分配太大，通常設置16M夠用了，默認8M，如果設置的內存大小不夠，InnoDB 會自動申請更多的內存，並在 MySQL 的 Error Log 中記錄警告信息。

innodb_log_buffer_size （日誌緩沖）

表示InnoDB寫入到磁碟上的日誌文件時使用的緩沖區的位元組數，默認值為16M。一個大的日誌緩沖區允許大量的事務在提交之前不用寫日誌到磁碟，所以如果有更新，插入或刪除許多行的事務，則使日誌緩沖區更大一些可以節省磁碟IO

通常最大設為64M足夠

max_connections (最大並發連接)

MySQL的max_connections參數用來設置最大連接（用戶）數。每個連接MySQL的用戶均算作一個連接，max_connections的默認值為100。

• 這個參數實際起作用的最大值（實際最大可連接數）為16384，即該參數最大值不能超過16384，即使超過也以16384為准；

• 增加max_connections參數的值，不會佔用太多系統資源。系統資源（CPU、內存）的佔用主要取決於查詢的密度、效率等；

• 該參數設置過小的最明顯特徵是出現」Too many connections」錯誤

• mysql> show variables like '%max_connect%';


• +-----------------------+-------+


• | Variable_name | Value |


• +-----------------------+-------+


• | extra_max_connections | 1 |


• | max_connect_errors | 100 |


• | max_connections | 2048 |


• +-----------------------+-------+3 rows in set (0.00 sec)



• mysql> show status like 'Threads%';


• +-------------------+---------+


• | Variable_name | Value |


• +-------------------+---------+


• | Threads_cached | 0 |


• | Threads_connected | 1 |


• | Threads_created | 9626717 |


• | Threads_running | 1 |


• +-------------------+---------+4 rows in set (0.00 sec)



可以看到此時的並發數也就是Threads_connected=1，還遠遠達不到2048

• mysql> show variables like 'open_files_limit';


• +------------------+-------+


• | Variable_name | Value |


• +------------------+-------+


• | open_files_limit | 65535 |


• +------------------+-------+1 row in set (0.00 sec)



max_connections 還取決於操作系統對單進程允許打開最大文件數的限制

也就是說如果操作系統限制單個進程最大可以打開100個文件

那麼 max_connections 設置為200也沒什麼用

MySQL 的 open_files_limit 參數值是在MySQL啟動時記錄的操作系統對單進程打開最大文件數限制的值

可以使用 show variables like 'open_files_limit'; 查看 open_files_limit 值

• ulimit -n65535



或者直接在 linux 下通過ulimit -n命令查看操作系統對單進程打開最大文件數限制 ( 默認為1024 )

connection級內存參數(線程獨享)

connection級參數，是在每個connection第一次需要使用這個buffer的時候，一次性分配設置的內存。

排序性能

mysql對於排序,使用了兩個變數來控制sort_buffer_size和 max_length_for_sort_data, 不象oracle使用SGA控制. 這種方式的缺點是要單獨控制,容易出現排序性能問題.

• mysql> SHOW GLOBAL STATUS like '%sort%';


• +---------------------------+--------+


• | Variable_name | Value |


• +---------------------------+--------+


• | Sort_merge_passes | 0 |


• | Sort_priority_queue_sorts | 1409 |


• | Sort_range | 0 |


• | Sort_rows | 843479 |


• | Sort_scan | 13053 |


• +---------------------------+--------+5 rows in set (0.00 sec)



• 如果發現Sort_merge_passes的值比較大，你可以考慮增加sort_buffer_size來加速ORDER BY 或者GROUP BY 操作,不能通過查詢或者索引優化的。我們這為0，那就沒必要設置那麼大。

讀取緩存

read_buffer_size = 128K(默認128K)為需要全表掃描的MYISAM數據表線程指定緩存

read_rnd_buffer_size = 4M：(默認256K)首先，該變數可以被任何存儲引擎使用，當從一個已經排序的鍵值表中讀取行時，會先從該緩沖區中獲取而不再從磁碟上獲取。

大事務binlog

• mysql> show global status like 'binlog_cache%';


• +-----------------------+----------+


• | Variable_name | Value |


• +-----------------------+----------+


• | Binlog_cache_disk_use | 220840 |


• | Binlog_cache_use | 67604667 |


• +-----------------------+----------+2 rows in set (0.00 sec)



• Binlog_cache_disk_use表示因為我們binlog_cache_size設計的內存不足導致緩存二進制日誌用到了臨時文件的次數

• Binlog_cache_use 表示 用binlog_cache_size緩存的次數

• 當對應的Binlog_cache_disk_use 值比較大的時候 我們可以考慮適當的調高 binlog_cache_size 對應的值

• 如上圖，現網是32K，我們加到64K

join語句內存影響

如果應用中，很少出現join語句，則可以不用太在乎join_buffer_size參數的設置大小。

如果join語句不是很少的話，個人建議可以適當增大join_buffer_size到1MB左右，如果內存充足可以設置為2MB。

線程內存影響

Thread_stack：每個連接線程被創建時，MySQL給它分配的內存大小。當MySQL創建一個新的連接線程時，需要給它分配一定大小的內存堆棧空間，以便存放客戶端的請求的Query及自身的各種狀態和處理信息。

• mysql> show status like '%threads%';


• +-------------------------+---------+


• | Variable_name | Value |


• +-------------------------+---------+


• | Delayed_insert_threads | 0 |


• | Slow_launch_threads | 0 |


• | Threadpool_idle_threads | 0 |


• | Threadpool_threads | 0 |


• | Threads_cached | 0 |


• | Threads_connected | 1 |


• | Threads_created | 9649301 |


• | Threads_running | 1 |


• +-------------------------+---------+8 rows in set (0.00 sec)



• mysql> show status like 'connections';


• +---------------+---------+


• | Variable_name | Value |


• +---------------+---------+


• | Connections | 9649311 |


• +---------------+---------+1 row in set (0.00 sec)



如上：系統啟動到現在共接受到客戶端的連接9649311次，共創建了9649301個連接線程，當前有1個連接線程處於和客戶端連接的狀態。而在Thread Cache池中共緩存了0個連接線程(Threads_cached)。

Thread Cache 命中率：

• Thread_Cache_Hit = (Connections - Threads_created) / Connections * 100%;



一般在系統穩定運行一段時間後，Thread Cache命中率應該保持在90%左右才算正常。

內存臨時表

tmp_table_size 控制內存臨時表的最大值,超過限值後就往硬碟寫，寫的位置由變數 tmpdir 決定

max_heap_table_size 用戶可以創建的內存表(memory table)的大小.這個值用來計算內存表的最大行數值。

Order By 或者Group By操作多的話，加大這兩個值，默認16M

• mysql> show status like 'Created_tmp_%';


• +-------------------------+-------+


• | Variable_name | Value |


• +-------------------------+-------+


• | Created_tmp_disk_tables | 0 |


• | Created_tmp_files | 626 |


• | Created_tmp_tables | 3 |


• +-------------------------+-------+3 rows in set (0.00 sec)



• 如上圖，寫入硬碟的為0，3次中間表，說明我們的默認值足夠用了

mariadb 推薦配置

• 注意這里只推薦innodb引擎

• 內存配置只關注有注釋的行

• [mysqld]


• datadir=/var/lib/mysql


• socket=/var/lib/mysql/mysql.sockdefault-storage-engine=INNODB



• character-set-server=utf8


• collation-server=utf8_general_ci



• user=mysql


• symbolic-links=0# global settings


• table_cache=65535table_definition_cache=65535max_allowed_packet=4M


• net_buffer_length=1M


• bulk_insert_buffer_size=16M



• query_cache_type=0 #是否使用查詢緩沖,0關閉


• query_cache_size=0 #0關閉，因為改表操作多，命中低，開啟消耗cpu



• # shared


• key_buffer_size=8M #保持8M MyISAM索引用


• innodb_buffer_pool_size=4G #DB專用mem*50%，非DB專用mem*15%到25%


• myisam_sort_buffer_size=32M


• max_heap_table_size=16M #最大中間表大小


• tmp_table_size=16M #中間表大小



• # per-thread


• sort_buffer_size=256K #加速排序緩存大小


• read_buffer_size=128k #為需要全表掃描的MYISAM數據表線程指定緩存


• read_rnd_buffer_size=4M #已排序的表讀取時緩存，如果比較大內存就到6M


• join_buffer_size=1M #join語句多時加大，1-2M


• thread_stack=256k #線程空間，256K or 512K


• binlog_cache_size=64K #大事務binlog




• # big-tables


• innodb_file_per_table = 1skip-external-locking


• max_connections=2048 #最大連接數


• skip-name-resolve



• # slow_query_log


• slow_query_log_file = /var/log/mysql-slow.log


• long_query_time = 30group_concat_max_len=65536# according to tuning-primer.sh


• thread_cache_size = 8thread_concurrency = 16# set variables


• concurrent_insert=2



運行時修改

使用以下命令來修改變數

• set global {要改的key} = {值}; （立即生效重啟後失效）


• set @@{要改的key} = {值}; （立即生效重啟後失效）


• set @@global.{要改的key} = {值}; （立即生效重啟後失效）



試驗

• mysql> set @@global.innodb_buffer_pool_size=4294967296;


• ERROR 1238 (HY000): Variable 'innodb_buffer_pool_size' is a read only variable


• mysql> set @@global.thread_stack=262144;


• ERROR 1238 (HY000): Variable 'thread_stack' is a read only variable


• mysql> set @@global.binlog_cache_size=65536;


• Query OK, 0 rows affected (0.00 sec)


• mysql> set @@join_buffer_size=1048576;


• Query OK, 0 rows affected (0.00 sec)


• mysql> set @@read_rnd_buffer_size=4194304;


• Query OK, 0 rows affected (0.00 sec)


• mysql> set @@sort_buffer_size=262144;


• Query OK, 0 rows affected (0.00 sec)


• mysql> set @@read_buffer_size=131072;


• Query OK, 0 rows affected (0.00 sec)


• mysql> set global key_buffer_size=8388608;


• Query OK, 0 rows affected (0.39 sec)



• 我們可以看到innodb_buffer_pool_size和thread_stack報錯了，他們只能改配置文件，在運行時是只讀的。 以下直接復制使用

• set @@global.binlog_cache_size=65536;


• set @@join_buffer_size=1048576;


• set @@read_rnd_buffer_size=4194304;


• set @@sort_buffer_size=262144;


• set @@read_buffer_size=131072;


• set global key_buffer_size=8388608;

㈢ 如何解決伺服器CPU使用率過高的問題

第一步：定位出來使用資源CPU最多的進程，不管是Windows還是linux或者Mac，這個都可以通過任務管理器很快的定位出來。
第二步：定位為什麼這個進程耗費CPU資源多。通常的原因有：程序本身本身就是CPU密集型的任務，而且程序正處於工作狀態；某些後台軟體也有可能執行一些CPU密集型的任務，比如殺毒軟體等。
第三步：解決問題。可以通過如下一些方式解決：更換硬體配置，換上更高配的硬體；軟體更換，使用一些佔用CPU資源更少的軟體。

㈣ 什麼會使伺服器CPU佔用過大

轉

伺服器正常運行CUP一般應該都在60%以下,有時候CUP出現上下波動很大,或者是伺服器突然很卡,或很慢.查看任務管理器,可以發現很多的w3wp.exe消耗CPU,結束後立即有新的w3wp.exe出現佔CPU,管管理員在這種情況.只好重新啟動IIS服務，奇怪的是，重新啟動IIS服務後一切正常，但可能過了一段時間後，問題又再次出現了。

直接原因：
有一個或多個ACCESS資料庫在多次讀寫過程中損壞，微軟的MDAC系統在寫入這個損壞的ACCESS文件時，ASP線程處於BLOCK狀態，結果其他線程只能等待，IIS被死鎖了，全部的CPU時間都消耗在w3wp.exe中。

解決辦法：1
在iis管理器裡面設置多個應用程序池， 並把虛擬主機站點分別加入應用程序池。在多應用程序池的情況下，每個應用程序池會對應生成一個w3wp.exe文件。通過任務管理器可以查看到所有w3wp.exe佔用cpu利用率情況。 通過iis管理器打開應用程序池，可以逐個停掉應用程序池。一邊停應用程序池，一邊在任務管理器裡面觀察哪個w3wp.exe的cpu利用率一下子從降下來，cpu利用率恢復正常。這樣可以判斷是那個應用程序池出了問題。然後可以再建立多個應用程序池，每一個應用程序池對應一個站點。這樣逐個停應用程序池，就可以確定到底是哪個網站出問題。最有問題的往往是計數器類的ACCESS文件，例如：「**COUNT.MDB」 ，「*COUNT.ASP」，找到這個文件後，可以刪除它，或下載下來，用ACCESS2000修復它，問題就解決。

解決辦法：2
w3wp.exe佔用cpu過高查詢方法,很多web提供商最頭疼的問題,在任務管理器經常出現w3wp.exe佔cup過高,導致整台伺服器受影響.解決辦法如下:
1.先把任務管理器打開,發現那個w3wp.exe佔cup關高就結束進程
2.在我的電腦-管理-事件查看器-系統-會找到關w3wp.exe的錯誤報告,把程序池名字記錄下,再把具體時間記錄下來.(如12.59.56).
3.在到系統上面的安全性.找到對應時間(如12.59.56)登陸過的用戶.
4.打開iis找到2中查詢到的程序池,和3查詢到登陸過的用戶,取交集,即可精確查到是那個web占點站cup.

還不明白，看這里：