• 4

AMD將出 32核心的x86 cpu叫Zen + Itanium Kittson

threefran wrote:
挖掘機呢?...(恕刪)

挖掘機架構跟壓路機架構一樣,僅會用在APU。

threefran wrote:
所以可能會是潮fm3...(恕刪)

AM3+會被拋棄是預料中的事情
只是不知道下一個使用的腳座是FM3還是AM4還是LGA <--也有聽說會改用LGA

fedora wrote:
1C2T 和 1M2C...(恕刪)


看來先進是行內的
這1 2年聽業界朋友說
AMD 幾乎在server 市場被打趴
根本沒案子

只希望amd這顆能準時出現
不然真的要找中共金主聲援一下

AMD這1年裁了不少人
某些大頭都被砍了
全球都在看 台裔lisa大媽怎麼救火

不過新一代FX都生不出來
大概現在也沒甚麼rd 資源玩了

會需要那麼多核心主要是web server 大量的連線需求嗎?
那nginx 跟apache 比較起來也是這樣嗎??

貝多芬 第九號交響曲 wrote:
看來先進是行內的這1...(恕刪)

apache比較吃浮點吧,amd在這方面根本被壓著打

貝多芬 第九號交響曲 wrote:
會需要那麼多核心主要是web server 大量的連線需求嗎?
那nginx 跟apache 比較起來也是這樣嗎??...(恕刪)


httpd.conf 中

MPM (Multi-Processing Module) 模組



直接轉貼網路上的解說:

Apache 的 MPM (Multi-Processing Module) 模組,是讓 Apache 以多重處理器的方式來處理要求 ,可以讓 Apache 更有效率的以較少的資源處理更多的服務要求,這個 MPM 還分成 worker 及 prefork 兩個子模組。

worker 採用 Multi-Thread (多重執行緒 ) 的方式,適合運用在一顆CPU有許多核心。

Pre-Forking 的方式則是 prefork (預載分流) 的運行方式,適合在一片主機板插很多顆CPU,比較佔用記憶體,但相容性及穩定性較佳。


超過這邊指定的數量,比方說上限是 1024,那麼當第 1025 個連線請求近來,httpd 會回應錯誤代碼:

500 Internal Server Error

503 Service Unavailable

就是伺服器繁忙、過載、掛掉...的意思。


在不重新編譯 apache 的情況下,ServerLimit 預設最大可以指定 2萬 個連線數

不過指定愈多,RAM 就會吃愈大。

此外這只是加大 排程佇列 快取,實際上 CPU 處理速度是不會改變的。


連線請求會暫時先放在 RAM 中,排程佇列 等候 CPU 處理。

比如 CPU 有併發4執行緒的處理能力,而上限是可以設定超過4的,因為連線請求可以先放在 RAM 中佇列排程,等候處理。

只不過等的人就要等比較久,處理結果(畫面)才會出來。

處理結果也是先放在 RAM 中,等候網卡輸出。

若 RAM 吃超過實體記憶體,使用到硬碟 SWAP 反而會降速。

比喻:
可看做一家餐廳很熱門,門外排隊區擴大(排程佇列快取擴大),讓更多人可以在那邊排隊,而不是直接打道回府。但排隊的人也是要等裡面的人吃完,才能進去。

廚房的做菜速度並沒有改變,若要加快出餐速度,得擴充廚房(核心)才行。





↑ 多核心,與 HT超執行緒 比較圖

多核心: 實體執行緒,一個核心至少有一個執行緒通道。

超執行緒:模擬的執行緒,使用一種技術欺騙作業系統,使 OS 以為在和兩顆CPU打交道。在 CPU 執行週期的空閒、空檔中,插入另一個線程去處理,使週期之間不至於有閒置浪費。

順暢度來講,是實體執行緒比較高。

因為模擬的需要額外的演算,此外也不見得週期之間就一定有大量空閒,要是沒有空閒當然就插入不了。


圖中每個點或方塊,可看做一個線程(以伺服器來講就是一個連線請求)。

若有愈多的執行緒通道(核心),就能一次併發處理更多的線程。

每個核心的處理性能不需要很高,因為那些連線請求都不是很重的運算,而通道數多是非常有利的,可以大幅提高一次處理的數量。

CPU 快慢也是有差,但執行緒通道數差別更大。

因為 CPU 有所謂的處理週期(震盪週期),在一段時間中,比如 1ms 毫秒,它只能接受一道指令。

縱使 CPU 速度再快,也只是處理結果的時間縮短,但在一個震盪週期時間內,仍是只能接受一道指令,那是它的先天物理限制。

但如果 CPU 數量很多(或者核心很多),在一個週期內,每個核心都能接受一道指令,有多個核心,就能接受多道指令。


**********************************************

nginx 沒研究,爬資料是說:天生對多執行緒的優化比 Apache 好,還有原生就支援 fastCGI。

它的運作原理,也是需要多核心(或多執行緒)才會有更佳的性能。


凡是需要 多線程 處理的軟體,應該不只 web server。

伺服器應用,比如:SQL資料庫查詢/寫入、郵件收發、proxy代理.....等等的,核心多(執行緒多)都是有好處的。

核心愈多,一次能併發處理的線程量,就愈多。

才不會請求一直卡在 排程佇列中,等候處理,等老半天。

主要可提高響應速度,瀏覽或使用服務的人,點擊下去,馬上響應不用等。
fedora wrote:

超執行緒:模擬的執行緒,使用一種技術欺騙作業系統,使 OS 以為在和兩顆CPU打交道。在 CPU 執行週期的空閒、空檔中,插入另一個線程去處理,使週期之間不至於有閒置浪費。
順暢度來講,是實體執行緒比較高。
因為模擬的需要額外的演算,此外也不見得週期之間就一定有大量空閒,要是沒有空閒當然就插入不了。圖中每個點或方塊,可看做一個線程(以伺服器來講就是一個連線請求)。
若有愈多的執行緒通道(核心),就能一次併發處理更多的線程。
每個核心的處理性能不需要很高,因為那些連線請求都不是很重的運算,而通道數多是非常有利的,可以大幅提高一次處理的數量。
CPU 快慢也是有差,但執行緒通道數差別更大。
因為 CPU 有所謂的處理週期(震盪週期),在一段時間中,比如 1ms 毫秒,它只能接受一道指令。
縱使 CPU 速度再快,也只是處理結果的時間縮短,但在一個震盪週期時間內,仍是只能接受一道指令,那是它的先天物理限制。
但如果 CPU 數量很多(或者核心很多),在一個週期內,每個核心都能接受一道指令,有多個核心,就能接受多道指令。

...(恕刪)

你對於HyperThreading的圖貼對了,但是解說卻全錯了,紅色是錯得最嚴重的部分,先卡位,晚點再來回覆。
雖然AMD這次應打翻身仗。已經好幾代被Intel擊敗,害現在高階CPU都是Intel的天下。
希望zen核心,AMD把快取記憶體的ECC效率跟區塊獨立出來
模塊是好的概念,可以DX12來的太慢
已經確定了,下一代FX跟APU全面進入14nm
共用FM3插座
看圖,APU是SoC包含晶片組
所以FX和APU雖然共用FM3腳位,但主機版應該不能通用

  • 4
內文搜尋
X
評分
評分
複製連結
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?