1、區域網訪問伺服器很慢
1. 以管理員方式啟動一個命令行窗口（Win+R 輸入cmd按Ctrl+Shift+Enter）
2. 在命令行窗口中輸入：netsh interface tcp set global autotuninglevel=disabled
後面那條命令可以改為下面的，據說速度更快：
netsh interface tcp set global autotuninglevel=highlyrestricted
問題原因： Receive Window Auto-Tuning是Vista 和Win 7引入的QoS(服務質量控制)的一部分，主要內容是動態調節TCP接收窗口（可以理解為緩沖區）大小，這個東西對QoS來說有很多好處（參考原文解釋），但它對發送端預設（假設目標TCP接收窗口）比較小的應用就會大大增加數據報告時間（我的理解，感興趣可以參考原文），這樣>6.0的遠程桌面就會被延遲很厲害。
而上面的命令的作用就是關閉或限制自動調節TCP接收窗口大小的功能，使之更接近低版（<=5.1?）RDP伺服器的假設，特別是highlyrestricted這個選項，並不是關閉該功能，而是限制功能，保守地使用這個功能，因此是比較折衷的方案，它保留了Receive Window Auto-Tuning帶來的好處，同時解決了（甚至提高了）遠程桌面的速度。
2、伺服器訪問速度一般受什麼限制？
1、伺服器的放置環境。
伺服器的放置環境影響著伺服器的穩定性大家都知道，但是伺服器機房的帶寬大小，影響著網站伺服器的訪問速度這個卻很少有人關注。機房帶寬越大，伺服器的訪問速度也就越快。這也是為什麼有些機房網站伺服器配置相對低於其它機房，但是伺服器租用價格卻很高的一個原因。
2、伺服器的配置。
伺服器就像是一台計算機，內存越大、處理器越好、硬碟越大，運行速度當然也就越快。
3、網站優化好壞。
伺服器對於網站來說，就像是一個家，一個可以存放東西的空間，如果說空間裡面雜亂無章，佔中的空間就比較大，用戶在訪問時讀取的速度就會變慢，從而影響著網站的訪問速度。因此站長朋友在做SEO的時候，也要盡量優化網站內部的代碼結構，使用CSS調用，注意HTML文檔的大小，網站圖片、嵌入的腳本、視頻等盡量優化之後再上傳等。
3、區域網電腦訪問伺服器速度很慢
大的原因有兩個：
1 你的PC問題，比如： 有網路進程在運行，佔用了你的網卡轉發能力，可以再任務管理器里看看； 打開瀏覽器時，CPU或者內存使用率太高，機子本身就反應很慢，建議結束一些不用的程序運行；可能在區域網中被限速了，需要跟網管聯系啊；
2 你訪問的伺服器有問題，訪問的用戶太多了、最大訪問數達到了、伺服器系統在更新等等！
4、訪問伺服器速度慢，打開文件夾都卡
找個情況我也碰到過，有個方法解決。 第一 檢查硬體線路，特別是硬碟，數據傳輸線路 很多問題不一定是軟體的錯。可能是硬體問題。
第二 樓下的說的有點道理 是共享的原因。建議設置下交換機 路由器
第三 系統問題，實在不行就還原系統把 很多毛病有時候搞半天也出不來。直接還原備份的系統 再設置下 就好啦 呵呵 祝你好運！
5、伺服器運行速度為什麼這么慢
影響伺服器運行速度的有以下因素：
(1)伺服器的硬體配置(包括伺服器的類型、CPU、硬碟速度、內存大小、網卡速度等)。
(2)伺服器所在的網內環境與速度。
(3)伺服器所在的網路環境與Internet骨幹網。
(4)機房與ChinaNet相聯的機房出口速率。
(5)ChinaNet的國際出口速率。
(6)訪問者的ISP (Internet接入服務提供商)與ChinaNet之間的專線速率。
(7)訪問者的ISP (Internet接入服務提供商)向客戶端開放的埠接入速率。
(8)訪問者計算機的配置，Modem的速率、電話線路的質量等。
(9)訪問網站的網頁結構、網頁大小、頁調用圖片其其它文件的數量及大小。
6、伺服器官網訪問很慢？
看下這些js文件的路徑是不是本身就慢，如果確定是js文件的原因可以更換js文件路徑，或者講js文件下載到本地
7、為什麼伺服器網站訪問很慢
1.IIS上做的限制,如IIS連接數或帶寬流量限制(IIS上有個限制網站流量,千位元組/S為單位),我有個客戶就自己在IIS上限制了1千位元組/S...結果網站開半天才能打開,但PING又正常!
2.伺服器網路問題,可能那100M共享的機櫃你去測試下你那台能用的帶寬是多少.
3.伺服器硬體配置問題,可能那伺服器上掛了幾百個網站,CPU使用率100%,資源被耗盡了.
8、web伺服器訪問緩慢，作為運維人員，如何定位故障
遇到伺服器故障，問題出現的原因很少可以一下就想到。我們基本上都會從以下步驟入手：
一、盡可能搞清楚問題的前因後果
不要一下子就扎到伺服器前面，你需要先搞明白對這台伺服器有多少已知的情況，還有故障的具體情況。不然你很可能就是在無的放矢。
必須搞清楚的問題有：
故障的表現是什麼？無響應？報錯？
故障是什麼時候發現的？
故障是否可重現？
有沒有出現的規律（比如每小時出現一次）
最後一次對整個平台進行更新的內容是什麼（代碼、伺服器等）？
故障影響的特定用戶群是什麼樣的(已登錄的, 退出的, 某個地域的…)?
基礎架構（物理的、邏輯的）的文檔是否能找到?
是否有監控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic…
什麼都可以）
是否有日誌可以查看?. （比如Loggly、Airbrake、 Graylog…）
最後兩個是最方便的信息來源，不過別抱太大希望，基本上它們都不會有。只能再繼續摸索了。
二、有誰在?
代碼如下:
$ w
$ last
用這兩個命令看看都有誰在線，有哪些用戶訪問過。這不是什麼關鍵步驟，不過最好別在其他用戶正幹活的時候來調試系統。有道是一山不容二虎嘛。（ne cook in
the kitchen is enough.）
三、之前發生了什麼?
$
history查看一下之前伺服器上執行過的命令。看一下總是沒錯的，加上前面看的誰登錄過的信息，應該有點用。另外作為admin要注意，不要利用自己的許可權去侵犯別人的隱私哦。
到這里先提醒一下，等會你可能會需要更新 HISTTIMEFORMAT
環境變數來顯示這些命令被執行的時間。對要不然光看到一堆不知道啥時候執行的命令，同樣會令人抓狂的。
四、現在在運行的進程是啥?
代碼如下:
$ pstree -a
$ ps aux
這都是查看現有進程的。 ps aux 的結果比較雜亂， pstree -a 的結果比較簡單明了，可以看到正在運行的進程及相關用戶。
五、監聽的網路服務
代碼如下:
$ netstat -ntlp
$ netstat -nulp
$
netstat -nxlp
我一般都分開運行這三個命令，不想一下子看到列出一大堆所有的服務。netstat -nalp倒也可以。不過我絕不會用 numeric 選項
（鄙人一點淺薄的看法：IP 地址看起來更方便）。
找到所有正在運行的服務，檢查它們是否應該運行。查看各個監聽埠。在netstat顯示的服務列表中的PID 和 ps aux 進程列表中的是一樣的。
如果伺服器上有好幾個Java或者Erlang什麼的進程在同時運行，能夠按PID分別找到每個進程就很重要了。
通常我們建議每台伺服器上運行的服務少一點，必要時可以增加伺服器。如果你看到一台伺服器上有三四十個監聽埠開著，那還是做個記錄，回頭有空的時候清理一下，重新組織一下伺服器。
六、CPU 和內存
代碼如下:
$ free -m
$ uptime
$ top
$
htop
注意以下問題:
還有空餘的內存嗎? 伺服器是否正在內存和硬碟之間進行swap?
還有剩餘的CPU嗎? 伺服器是幾核的? 是否有某些CPU核負載過多了?
伺服器最大的負載來自什麼地方? 平均負載是多少?
七、硬體
代碼如下:
$ lspci
$ dmidecode
$
ethtool
有很多伺服器還是裸機狀態，可以看一下：
找到RAID 卡 (是否帶BBU備用電池?)、 CPU、空餘的內存插槽。根據這些情況可以大致了解硬體問題的來源和性能改進的辦法。
網卡是否設置好?
是否正運行在半雙工狀態? 速度是10MBps? 有沒有 TX/RX 報錯?
八、IO 性能
代碼如下:
$ iostat -kx 2
$ vmstat 2 10
$ mpstat
2 10
$ dstat --top-io --top-bio
這些命令對於調試後端性能非常有用。
檢查磁碟使用量：伺服器硬碟是否已滿?
是否開啟了swap交換模式 (si/so)?
CPU被誰佔用：系統進程? 用戶進程? 虛擬機?
dstat 是我的最愛。用它可以看到誰在進行 IO： 是不是MySQL吃掉了所有的系統資源? 還是你的PHP進程?
九、掛載點 和 文件系統
代碼如下:
$ mount
$ cat /etc/fstab
$ vgs
$
pvs
$ lvs
$ df -h
$ lsof +D / /* beware not to kill your box
*/
一共掛載了多少文件系統?
有沒有某個服務專用的文件系統? (比如MySQL?)
文件系統的掛載選項是什麼： noatime?
default? 有沒有文件系統被重新掛載為只讀模式了？
磁碟空間是否還有剩餘?
是否有大文件被刪除但沒有清空?
如果磁碟空間有問題，你是否還有空間來擴展一個分區？
十、內核、中斷和網路
代碼如下:
$ sysctl -a | grep ...
$ cat
/proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy
servers */
$ netstat
$ ss -s
你的中斷請求是否是均衡地分配給CPU處理，還是會有某個CPU的核因為大量的網路中斷請求或者RAID請求而過載了？
SWAP交換的設置是什麼？對於工作站來說swappinness 設為 60 就很好,
不過對於伺服器就太糟了：你最好永遠不要讓伺服器做SWAP交換，不然對磁碟的讀寫會鎖死SWAP進程。
conntrack_max 是否設的足夠大，能應付你伺服器的流量?
在不同狀態下(TIME_WAIT, …)TCP連接時間的設置是怎樣的？
如果要顯示所有存在的連接，netstat 會比較慢， 你可以先用 ss 看一下總體情況。
你還可以看一下 Linux TCP tuning
了解網路性能調優的一些要點。
十一、系統日誌和內核消息
代碼如下:
$ dmesg
$ less /var/log/messages
$
less /var/log/secure
$ less /var/log/auth
查看錯誤和警告消息，比如看看是不是很多關於連接數過多導致？
看看是否有硬體錯誤或文件系統錯誤?
分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。
十二、定時任務
代碼如下:
$ ls /etc/cron* + cat
$ for user in
$(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done
是否有某個定時任務運行過於頻繁?
是否有些用戶提交了隱藏的定時任務?
在出現故障的時候，是否正好有某個備份任務在執行？
十三、應用系統日誌
這里邊可分析的東西就多了,
不過恐怕你作為運維人員是沒功夫去仔細研究它的。關注那些明顯的問題，比如在一個典型的LAMP（Linux+Apache+Mysql+Perl）應用環境里:
Apache & Nginx; 查找訪問和錯誤日誌, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。
MySQL;
在mysql.log找錯誤消息，看看有沒有結構損壞的表， 是否有innodb修復進程在運行，是否有disk/index/query 問題.
PHP-FPM; 如果設定了 php-slow 日誌, 直接找錯誤信息 (php, mysql, memcache, …)，如果沒設定，趕緊設定。
Varnish; 在varnishlog 和 varnishstat 里, 檢查 hit/miss比.
看看配置信息里是否遺漏了什麼規則，使最終用戶可以直接攻擊你的後端？
HA-Proxy;
後端的狀況如何？健康狀況檢查是否成功？是前端還是後端的隊列大小達到最大值了？
結論
經過這5分鍾之後，你應該對如下情況比較清楚了：
在伺服器上運行的都是些啥？
這個故障看起來是和 IO/硬體/網路 或者 系統配置 (有問題的代碼、系統內核調優, …)相關。
這個故障是否有你熟悉的一些特徵？比如對資料庫索引使用不當，或者太多的apache後台進程。
你甚至有可能找到真正的故障源頭。就算還沒有找到，搞清楚了上面這些情況之後，你現在也具備了深挖下去的條件。繼續努力吧！
9、伺服器訪問緩慢怎麼辦了？？
帶寬低，或者線路沖突
10、伺服器響應慢是怎麼回事和怎麼解決響應速度慢
這種問題挺復雜的，有些原因真的很出意料，一般程式化的方法還找不到。
1.先用瀏覽器F12控台查看一下網頁載入資源的情況，看是不是某些資源載入慢的緣故。
2.如果不是的話， 那就檢查一下是不是網路問題。
3.如果都不是上面的問題，你再去看下伺服器的狀況，應該有後台可以看，看下是不是帶寬不足。（或者用top，iptraf命令看一下）
4.最後還有問題的話看下你php代碼是不是有問題，用xhprof看下代碼哪裡慢。
---------
例1：
伺服器: 戴爾 PowerEdge R620 Rack Mount Chassis
今天公司的 web伺服器響應異常的慢 平常 200ms 執行完畢的一個action，現在要 2秒多才能執行那個完畢。
之前也出現過這種狀況,但再重啟之後就一般及解決了。
遍歷網上
說是
1、網路原因 2、系統原因 3、硬體原因
首先分析網路原因 我 ping 伺服器的 接收到響應要1ms，平常都是小於 1ms
2、系統原因
我查看了任務管理器發現 CPU 橫容易就奔向100%了。
4 個cpu 核心 馬上沖向頂端持平了。
3、硬體原因
聽網上說可能還有一部分磁碟 i/o 也會導致運行速度大減的
2、3 部分圖片當時很著急解決問題沒有截圖、
下面是今天晚上伺服器 恢復正常後的基本空閑時的cpu 狀況、和磁碟讀取狀況
想問一下、普通我這種刀片伺服器正常運行時oracle 的一般最高讀寫速度、為什麼怎樣找到程序中那個可能正執行死循環的程序
經過之前一天的推測，覺得應該是伺服器上的另一個應用伺服器，出現了死循環，聯系了此程序開發人員讓其恢復了上一個版本，問題就沒有了。
就是那一個個驗證推測麻煩，花了我一天的時間，想直接知道哪裡死循環。
經過之前一天的推測，覺得應該是伺服器上的另一個應用伺服器，出現了死循環，聯系了此程序開發人員讓其恢復了上一個版本，問題就沒有了。
就是那一個個驗證推測麻煩，花了我一天的時間，想直接知道哪裡死循環。
例2：
我的WIN2003獨立伺服器（P4 2.8G/1G的方正商用機，非專業伺服器），ACCESS資料庫有800多兆，同時在線會員100多人。瀏覽速度很慢，日發帖從1000多銳減到200多貼，網友怨聲載道，不得已才轉換到DZ。
轉換後DZ的資料庫有600多兆。剛開始挺快的，隨後升級到DZ6.1，現在過了才1個多月，伺服器響應越來越慢。CPU佔用並不高，通常不到20%，內存佔用好像也正常。就是經常硬碟燈一直亮（是常亮，不是閃亮），每到這時論壇頁面就打不開，有時光顯示頁面頭部，要等很長時間。硬碟燈不常亮的時候速度挺快。
以前是一兩天出現一次，後來越來越頻繁，現在過不多大會兒就出現一次，簡直受不了了。
相信很多人在用windows2003伺服器或者vps，而且一開始用，速度都相當的快，但是過了幾天速度變慢了很多，也會遇到有時候網站打開卡等現象，即使網站沒什麼流量也會出現。
有時候就會懷疑是不是我的伺服器或者vps很差勁，買到假貨了？其實不然。
其實這些問題作祟的都是w3wp.exe這個iis進程在搗鬼。
在WINDOWS2003+IIS6下，經常出現w3wp的內存佔用不能及時釋放，從而導致伺服器響應速度很慢。
遇到這些現象，我們可以用以下方法進行解決，不影響網站運營及系統問題。
可以做以下配置修改進行改善：
1、在IIS中對每個網站進行單獨的應用程序池配置。即互相之間不影響。
2、設置應用程序池的回收時間，默認為1720小時，可以根據情況修改。同時，設置同時運行的web工作進程數目為1。再設置當內存或者cpu佔用超過多少，就自動回收內存。
一般來說就可以解決了。但仍然會出現個別網站因為程序問題，不能正確釋放。
那麼，怎麼樣才能找到是哪一個網站的？解決辦法：
1、在任務管理器中增加顯示pid欄位。就可以看到佔用內存或者cpu最高的進程pid
2、在命令提示符下運行iisapp -a。注意，第一次運行，會提示沒有js支持，點擊確定。然後再次運行就可以了。這樣就可以看到pid對應的應用程序池
3、到iis中察看該應用程序池對應的網站，就可以了。