Amazon EC2, pembatalan mysql dimulai karena InnoDB: mmap (x bytes) gagal; errno 12


95

Saya telah menyiapkan server contoh mikro di EC2 berdasarkan apa yang saya baca di sini

server mysql sering gagal dan untuk ketiga kalinya server mysql hilang. Log hanya menunjukkan

120423 09:13:38 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120423 09:14:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120423  9:14:27 [Note] Plugin 'FEDERATED' is disabled.
120423  9:14:27 InnoDB: The InnoDB memory heap is disabled
120423  9:14:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120423  9:14:27 InnoDB: Compressed tables use zlib 1.2.3
120423  9:14:27 InnoDB: Using Linux native AIO
120423  9:14:27 InnoDB: Initializing buffer pool, size = 512.0M
InnoDB: mmap(549453824 bytes) failed; errno 12
120423  9:14:27 InnoDB: Completed initialization of buffer pool
120423  9:14:27 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120423  9:14:27 [ERROR] Plugin 'InnoDB' init function returned error.
120423  9:14:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120423  9:14:27 [ERROR] Unknown/unsupported storage engine: InnoDB
120423  9:14:27 [ERROR] Aborting

Apa sebenarnya failed; errno 12? Dan bagaimana saya bisa memberi lebih banyak ruang / memori atau apa pun yang diperlukan untuk memperbaikinya.

Saya memperbaikinya setiap kali dengan me-reboot seluruh sistem dan menghapus semua log dan memulai ulang server mysql. Tapi saya tahu ada yang salah dengan konfigurasi saya.

Juga my.cnf saya seperti di bawah ini:

[mysqld]
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under different user or group,
# customize your systemd unit file for mysqld according to the
# instructions in http://fedoraproject.org/wiki/Systemd
# max_allowed_packet=500M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0


innodb_buffer_pool_size         = 512M


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Saya memiliki masalah yang sama pada instans mikro EC2 saya. Telah mencoba mengatur innodb_buffer_pool_size = 128M dan akan melihat bagaimana kelanjutannya.
swxxii

Anda mungkin perlu menambahkan ruang swap jika Anda menggunakan contoh mikro: prowebdev.us/2012/05/amazon-ec2-linux-micro-swap-space.html
pmoubed

1
Pada Instans mikro EC2, TIDAK ada ruang swap secara default dan perlu disiapkan secara manual. Jika tidak, Anda mungkin melihat banyak MySQL crash karena kekurangan memori.
Diragukan

Jawaban:


163

Saya menemui masalah yang sama ketika saya mencoba menjalankan wordpress di instance mikro saya tanpa RDS.

Menambahkan halaman Swap memecahkan masalah bagi saya.

Anda dapat mengikuti langkah-langkah di bawah ini untuk mengatur ruang swap.

Jika masih tidak berhasil untuk Anda, pertimbangkan untuk menggunakan layanan RDS.

===============================================

Saya menyalin konten blog sebagai catatan. Penghargaan diberikan kepada penulis blog yang diragukan :

Ruang Swap Instans Mikro Amazon EC2 - Linux

Saya memiliki instance Amazon EC2 Linux Micro. Karena instans Mikro hanya memiliki memori 613MB, MySQL terkadang mengalami error. Setelah pencarian yang lama tentang MySQL, Micro Instance dan Memory Managment, saya menemukan bahwa tidak ada ruang SWAP default untuk instance Micro. Jadi, jika Anda ingin menghindari crash, Anda mungkin perlu menyiapkan ruang swap untuk instance mikro Anda. Sebenarnya performa bijaksana lebih baik untuk mengaktifkan swap.

Langkah-langkah di bawah ini menunjukkan cara membuat ruang swap untuk instans Mikro Anda. Saya berasumsi Anda memiliki Akun AWS dengan instans Mikro berjalan.

  1. Lari dd if=/dev/zero of=/swapfile bs=1M count=1024
  2. Lari mkswap /swapfile
  3. Lari swapon /swapfile
  4. Tambahkan baris ini /swapfile swap swap defaults 0 0ke/etc/fstab

Langkah 4 diperlukan jika Anda ingin mengaktifkan file swap secara otomatis setelah setiap reboot.

Beberapa perintah berguna yang terkait dengan ruang SWAP:

$ swapon -s   
$ free -k

$ swapoff -a
$ swapon  -a

Referensi:

  1. http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/
  2. http://cloudstory.in/2012/02/getting-the-best-out-of-amazon-ec2-micro-instances/
  3. http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/
  4. http://aws.amazon.com/ec2/instance-types/

Terima kasih! Ini membantu saya!
Urungkan

8
FYI, ini bekerja untuk saya pada tetesan Laut Digital (512 MB). Bukan berarti ini mengejutkan siapa pun, tetapi jika ada yang tidak yakin, ini mungkin akan berfungsi di server mana pun dengan masalah yang sama.
jfacemyer

Terima kasih untuk penyelamat ini! Juga menjalankan instance mikro dengan Server Ubuntu.
ECC-Dan

4
Untuk pengguna Digital Ocean, saya mengikuti tutorial ini dan bekerja seperti pesona: digitalocean.com/community/articles/…
Chris Ray

Terima kasih banyak. Telah menarik rambut saya selama 24 jam terakhir, bermain dengan semua jenis ukuran buffer / cache / query .. Anda adalah penyelamat!
pranshus

23

Saya mengalami masalah ini juga pada instans mikro Amazon EC2. Saya mencoba mengurangi penggunaan memori inno_db dengan menambahkan yang berikut ini ke/etc/my.cnf

innodb_buffer_pool_size = 64 juta

Itu tidak berhasil, saya mencoba menurunkannya ke 16M dan masih tidak berhasil. Kemudian saya menyadari bahwa instance tersebut pada dasarnya tidak memiliki memori kosong. Jadi saya mencoba memulai ulang apache

sudo system httpd restart
sudo system mysqld restart

Dan semuanya bekerja dengan baik. Mungkin solusi lain adalah mengkonfigurasi apache agar tidak memakan begitu banyak memori.


2
MySQL mungkin masih macet sehingga Anda mungkin perlu menambahkan ruang swap ke instance mikro Anda.
Diragukan

Terima kasih, itu masuk akal. Saya rasa saya juga dapat mencoba membatasi jumlah utas yang dapat muncul di apache.
wfbarksdale

Bekerja dengan baik. Saya memiliki masalah ini juga dan dengan memulai ulang httpd menyelesaikan masalah.
Lionel Chan

1
Tangkapan luar biasa, perahu yang sama di sini. Saya mengatur apache saya untuk menggunakan lebih sedikit ram dan juga membuat file swap 512m, tetapi mengatur vm.swappiness ke 10 sehingga hanya akan digunakan dalam keadaan darurat.
newz2000

Memulai ulang nginx dan php-fpm juga melepaskan cukup memori untuk memungkinkan mysql dimulai! Terima kasih!
msEmmaMays

4

Sepertinya Anda meminta memori 128M untuk innodb_buffer_pool_size di file my.cfg yang Anda tampilkan di posting, tetapi MySQL mengira Anda meminta memori 512M :

Menginisialisasi kumpulan buffer, size = 512.0M

Beberapa baris ke bawah, pesan kesalahan memberi tahu Anda MySQL tidak akan mulai karena tidak dapat mencadangkan cukup memori (512M) untuk kumpulan buffer InnoDB:

Kesalahan fatal: tidak dapat mengalokasikan memori untuk kumpulan buffer

Itu menimbulkan tiga pertanyaan:

  1. Berapa banyak memori di instans Anda? Haruskah ada cukup memori untuk menampung 512 juta InnoDB yang coba diraih untuk buffer pool, ditambah semua hal lain yang dialokasikan MySQL, ditambah aplikasi Anda, plus sistem operasi?
  2. Mengapa InnoDB mencoba mengambil lebih dari yang Anda kira seharusnya?
  3. Mengapa MySQL memulai ulang?

Anda bisa menjawab 1.

Untuk 2., ada beberapa tempat file opsi MySQL dapat ditemukan. Opsi penggantian file yang ditemukan selanjutnya ditentukan dalam file yang ditemukan sebelumnya. Lihat

http://dev.mysql.com/doc/refman/5.5/en/option-files.html

Masalah 3. dapat terjadi karena kondisi memori habis yang terjadi beberapa saat setelah startup. Anda harus melihat indikasi itu lebih jauh di log jika itu masalahnya.

Terakhir, tetapi agak tidak terkait, apakah Anda menggunakan instans yang didukung EBS? Itu umumnya sangat disarankan untuk server database (sebenarnya, untuk contoh apa pun yang melarang keadaan khusus). Untuk lebih lanjut tentang itu, lihat

https://stackoverflow.com/a/3630707/141172


2

Bagi saya, masalah ini telah diperbaiki dengan menambahkan volume swap ke instans EC2 saya. Layanan saya hanya menghabiskan semua memori di kotak, dan akan macet. Bukan sesuatu yang biasa saya lakukan, menjadi admin RedHat / CentOS selama bertahun-tahun - Anaconda melakukan BANYAK pekerjaan yang tidak dilakukan oleh instance Ubuntu EC2 gratis.

Saya cukup membuat volume 2Gb melalui konsol web, melampirkannya ke instance saya, dan melakukan "mkswap / dev / [apa saja]", mengedit / etc / fstab, dan kerusakan berhenti.

Instance ini TIDAK diinstal seperti penginstalan OS berbasis media yang biasa dilakukan sebagian besar dari kita - itu dilucuti tanpa paket, tidak ada sistem file yang tepat, dan hal-hal seperti AppArmor, yang menyebabkan semua jenis masalah jika Anda tidak menyadarinya dan / atau tidak tahu cara mengkonfigurasinya.


1

Masalahnya adalah server tidak memiliki cukup memori untuk dialokasikan untuk proses MySQL. Ada beberapa solusi untuk masalah ini.

(1) Tingkatkan RAM fisik. Menambahkan 1GB RAM tambahan akan menyelesaikan masalah. (2) Alokasikan ruang SWAP. Instans VPS Digital Ocean tidak dikonfigurasi untuk menggunakan ruang swap secara default. Dengan mengalokasikan 512MB ruang swap, kami dapat mengatasi masalah ini. Untuk menambahkan ruang swap ke server Anda, ikuti langkah-langkah berikut:

## As a root user, perform the following:
# dd if=/dev/zero of=/swap.dat bs=1024 count=512M
# mkswap /swap.dat
# swapon /swap.dat
## Edit the /etc/fstab, and the following entry.
/swap.dat      none    swap    sw      0       0 

Kurangi ukuran ukuran kumpulan buffer MySQL

## Edit /etc/my.cnf, and add the following line under the [mysqld] heading.
[mysqld]
innodb_buffer_pool_size=64M

Periksa juga Ruang Disk Anda. Pastikan Anda memiliki cukup ruang.

df-h


1

JAWABAN MUDAH:

* * * * * systemctl is-active --quiet mysqld || systemctl restart mysqld

JAWABAN RINCI:

Ini adalah pertanyaan penting terutama bagi orang yang menggunakan VPS yang sangat kecil, katakanlah RAM 1GB atau kurang. Jika MySQL tidak berfungsi, mungkin ada masalah dengan konfigurasi server Anda (Apache | nginx) atau konfigurasi MySQL. Serangan DOS dapat menyebabkan peningkatan penggunaan sumber daya sistem (lihat gambar). Hasil akhirnya adalah proses MySQL dimatikan oleh Kernel. Untuk solusi jangka panjang harus melihat mengoptimalkan konfigurasi Apache atau MySQL Anda.

Lonjakan sumber daya sistem menyebabkan lonjakan RAM (sebelum jam 6 sore) dan lonjakan sumber daya sistem hanya menyebabkan lonjakan CPU Tengah malam pada Selasa 18

Ada beberapa diskusi lain Stack Overflow topik-topik tersebut serta manual MySQL dan Blog Percona:

Manual MySQL - Bagaimana MySQL Menggunakan Memori:

https://dev.mysql.com/doc/refman/8.0/en/memory-use.html

Percona - Praktik Terbaik untuk Mengonfigurasi Penggunaan Memori MySQL yang Optimal:

https://www.percona.com/blog/2016/05/03/best-practices-for-configuring-optimal-mysql-memory-usage/

Cara Mengoptimalkan Kinerja MySQL Menggunakan MySQLTuner:

https://www.linode.com/docs/databases/mysql/how-to-optimize-mysql-performance-using-mysqltuner/

Konfigurasi Penggunaan Memori Apache:

/server/254436/apache-memory-usage-optimization

Manual Apache tentang Penyetelan Kinerja:

https://httpd.apache.org/docs/2.4/misc/perf-tuning.html

Tuning Apache Server:

https://www.linode.com/docs/web-servers/apache-tips-and-tricks/tuning-your-apache-server/

Namun, sehubungan dengan pertanyaan awal Anda, ya, Anda dapat membuat skrip solusi sementara yang memeriksa apakah layanan MySQL sudah dimuat dan aktif dan akan memulai ulang MySQL jika tidak dimuat dan aktif.

Anda tidak menyebutkan sistem operasi apa yang Anda gunakan. Itu akan membantu memberi Anda perintah khusus. Saya akan memberi Anda contoh untuk CentOS linux.
Lihatlah keluaran perintah berikut systemctl status mysql. Anda dapat melihat di bagian atas bahwa layanan dimuat dan aktif .

[root@centos-mysql-demo ~]# systemctl status mysqld
 mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-06-18 18:28:18 UTC; 924ms ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 3350 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=0/SUCCESS)
  Process: 3273 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 3353 (mysqld)
   CGroup: /system.slice/mysqld.service
           └─3353 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

Jun 18 18:28:11 centos-mysql-demo systemd[1]: Starting MySQL Server...
Jun 18 18:28:18 centos-mysql-demo systemd[1]: Started MySQL Server.

Jika layanan tidak dimuat, maka perintah seperti:

systemctl status mysqld || systemctl restart mysqld 

akan melakukan trik memulai kembali proses. Anda bisa mengatakan bahwa:

* * * * * systemctl status mysqld || systemctl restart mysqld

Namun, jika mysql dimuat , tetapi layanan tidak aktif , cron Anda tidak akan melakukan apa pun. Jadi, Anda harus menggunakan perintah yang lebih detail seperti:

* * * * * systemctl is-active --quiet mysqld || systemctl restart mysqld

Dalam kasus ini, jika layanan dimuat tetapi tidak aktif seperti status bahwa serangan DOS dapat meninggalkan layanan mysql Anda, perintah juga akan memulai ulang mysql. Menggunakan --quietbendera hanya menentukan perintah hanya untuk mengembalikan kode status, bukan menampilkan apa pun ke layar. Jika Anda mengabaikan --quietflag, Anda akan melihat keluaran status activeatau inactive.

Anda juga dapat membuat beberapa ruang swap untuk menambahkan lebih banyak sumber daya RAM yang tersedia ke server Anda seperti:

sudo dd if=/dev/zero of=/swapfile count=2096 bs=1MiB
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon --show
swapon --summary
free -h

0

Gunakan salah satu dari solusi berikut ini:

  1. Tingkatkan RAM fisik. Menambahkan 1GB RAM tambahan akan menyelesaikan masalah.

  2. Alokasikan ruang SWAP dengan menggunakan perubahan konfigurasi di bawah ini:

config

dd if=/dev/zero of=/extraswap bs=1024 count=512M
mkswap  /extraswap 
swapon  /extraswap 
## Edit the /etc/fstab, and the following entry.
/extraswap      none    swap    sw      0       0
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.