mysql經常報Out of memory (Needed 3143840 bytes) 求解決~~

1、試下：sort_buffer_size = 2M

創新互聯服務緊隨時代發展步伐，進行技術革新和技術進步，經過十余年的發展和積累，已經匯集了一批資深網站策劃師、設計師、專業的網站實施團隊以及高素質售后服務人員，并且完全形成了一套成熟的業務流程，能夠完全依照客戶要求對網站進行成都網站設計、網站制作、建設、維護、更新和改版，實現客戶網站對外宣傳展示的首要目的，并為客戶企業品牌互聯網化提供全面的解決方案。

read_buffer_size = 2M

2、找到出問題的SQL，減少select出來的字段的數量，優化語句。

mysql配置過大內存導致無法啟動怎么辦 如何解決

查看 /proc/meminfo

Tips：

“大內存頁”也稱傳統大頁、大頁內存等有助于 Linux 進行虛擬內存的管理，標準的內存頁為 4KB，這里使用“大內存頁”最大可以定義 1GB 的頁面大小，在系統啟動期間可以使用“大內存頁”為應用程序預留一部分內存，這部分內存被占用且永遠不會被交換出內存，它會一直保留在那里，直到改變配置。（詳細介紹請看下面鏈接官方解釋）

那么這么大頁內存是分配給誰的呢？

查詢一下：

shell /proc/sys/vm/hugetlb_shm_group

27

shell id 27

uid=27(mysql) gid=27(mysql) groups=27(mysql)

hugetlb_shm_group 文件里填的是指定大頁內存使用的用戶組 id，這里查看到是 MySQL 組 id，那既然是給 MySQL 的為什么 free 等于 total，并且 mysql 還只有 20 多 G 實際使用內存呢？

原來在 MySQL 中還有專門啟用大內存頁的參數，在 MySQL 大內存頁稱為 large page。

查看 MySQL 配置文件

發現配置文件中確實有 large-page 配置，但出于禁用狀態。

后與業務確認，很早之前確實啟用過 mysql 的 large page，不過后面禁用了。排查到這基本就有了結論。

結論

這套環境之前開啟了 20000 的大內存頁，每頁大小為 2MB，占用了 40G 內存空間，給 MySQL 使用，并且 MySQL 開啟了 large page，但后來不使用的時候，只關閉了 MySQL 端的 large page 參數，但沒有實際更改主機的關于大內存頁的配置，所以導致，實際上主機上的還存在 20000 的大內存頁，并且沒在使用，這一部分長期空閑，并且其他程序不能使用。

所以 MySQL 在使用 20G 內存左右，整個主機內存就飽和了，然后在部分條件下，就觸發了 OOM，導致 mysqld 被 kill，但主機上又有 mysqld_safe 守護程序，所以又再次給拉起來，就看到了文章初的偶爾連接不上的現象。

linux 下怎么優化mysql占用內存？

修改mysql配置文件，優化緩存大小和連接數連接方式，優化sql語句 ,記得mysql好像是有工具可以查看最占用資源的sql語句，找到他，優化他。

安裝好mysql后，配制文件應該在/usr/local/mysql/share/mysql目錄中，配制文件有幾個，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網站和不同配制的服務器環境，當然需要有不同的配制文件了。

一般的情況下，my-medium.cnf這個配制文件就能滿足我們的大多需要；一般我們會把配置文件拷貝到/etc/my.cnf 只需要修改這個配置文件就可以了，使用mysqladmin variables extended-status _u root _p 可以看到目前的參數，有3個配置參數是最重要的，即key_buffer_size,query_cache_size,table_cache。

key_buffer_size只對MyISAM表起作用，

key_buffer_size指定索引緩沖區的大小，它決定索引處理的速度，尤其是索引讀的速度。一般我們設為16M,實際上稍微大一點的站點　這個數字是遠遠不夠的，通過檢查狀態值Key_read_requests和Key_reads,可以知道key_buffer_size設置是否合理。比例 key_reads / key_read_requests應該盡可能的低，至少是1:100，1:1000更好（上述狀態值可以使用SHOW STATUS LIKE ‘key_read%’獲得）。 或者如果你裝了phpmyadmin 可以通過服務器運行狀態看到,筆者推薦用phpmyadmin管理mysql，以下的狀態值都是本人通過phpmyadmin獲得的實例分析:

這個服務器已經運行了20天

key_buffer_size _ 128M

key_read_requests _ 650759289

key_reads - 79112

比例接近1:8000 健康狀況非常好

Mysql 5.7服務開啟之后,占內存過多，怎么減小？

如果我們查看“top”命令的輸出，我們會看到：MySQL 5.7

MySQL 8.0

這也展示出 MySQL8 使用的更多常駐內存和虛擬內存。特別是“可怕的”虛擬內存，因為它遠遠超過這些 VM 上可用的 1GB 物理內存。當然，虛擬內存使用（VSZ）是現代應用程序實際內存需求的一個很差的指標，但它確實證實了更高的內存需求這個事。

實際上，正如我們從 “vmstat” 輸出中所知道的那樣，即使沒有太多的“空間”，MySQL 8 和 MySQL 5.7 都不會在低負載下使用 swap 分區。如果您有多個連接或希望在同一個 VM 上運行某些應用程序，則可以使用 swap（如果未啟用交換，則可能導致 OOM）。

這是一個有趣的實驗，能看看我有多少可以驅動 MySQL 5.7 和 MySQL 8 的內存消耗。