Menambah batas memori tidak membantu dalam kesalahan Fatal: Ukuran memori yang diperbolehkan dari ... / modules / views / views.module on line 416


11

Saya telah beralih dari Drupal 7.14 ke 7.15 tiga minggu lalu dan karenanya, saya menghadapi serangkaian kesalahan batas memori yang sangat canggih (untuk saya) . Kesalahan itu terjadi kapan saja saya mencoba untuk menghapus cache dalam kinerja atau untuk menjalankan skrip pembaruan.

Perusahaan hosting saya telah meningkatkan batas memori saya di php.ini hingga 126 M, 256 M, 512 M, dan bahkan 1024 M. Tetapi kesalahan masih terjadi. Saya telah memigrasikan situs saya dari dibagikan ke VPS, Tetapi kesalahan masih terjadi. Saya tidak punya cara dan tidak tahu bagaimana bergerak maju.

Berikut ini kesalahannya:

  • Kesalahan fatal: Ukuran memori yang diizinkan sebesar 536870912 byte habis (mencoba mengalokasikan 30 byte) di /home/example/public_html/sites/all/modules/views/views.module on line 416
  • Kesalahan fatal: Ukuran memori yang diizinkan sebesar 536870912 byte habis (mencoba mengalokasikan 108 byte) di /home/example/public_html/includes/menu.inc on line 2736

  • Kesalahan fatal: Ukuran memori yang diizinkan sebesar 536870912 byte habis (mencoba mengalokasikan 71 byte) di /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module on line 59

  • alokasikan 64 bytes) di /home/example/public_html/sites/all/modules/views/includes/base.inc on line 93


Apa lalu lintas puncak Anda (halaman / detik). Juga berapa banyak data (node?) Yang coba dilihat oleh view?
cherouvim

diskusi serupa di drupal.org drupal.org/node/76156
Anoop Joseph

2
Apakah Anda secara kebetulan memiliki tampilan yang mengembalikan sejumlah besar hasil dan untuk memformatnya memuat konten alih-alih bidang? Saya telah melihat ini menghambat kinerja berkali-kali sebelumnya.
Jepedo

Hai kawan! Terima kasih banyak atas jawaban Anda. Saya ingin mengatakan bahwa situs web sedang dalam mode pemeliharaan dan hanya berisi beberapa konten (node) untuk tujuan pengujian. Situs ini hanya dikunjungi oleh crawler Seperti yang saya sebutkan di posting saya, peningkatan batas memori dalam solusi php.ini yang disarankan dalam node drupal.org/node/76156 tidak membantu dalam kasus saya. Untuk tampilan memuat konten, bukan bidang. Saya ingin mengetahuinya bagaimana
salift

1
Sudahkah Anda mencoba beralih kembali ke Drupal 7.14? Jika memutakhirkan ke Drupal 7.15 menyebabkan masalah itu, lalu mengapa tidak mencoba beralih kembali? Firasat saya adalah bahwa ada rekursi tak terbatas di salah satu modul Anda. Apa modul terkait Tampilan Anda?
Johnathan Elmore

Jawaban:


13

Saya juga telah memukul kepala saya ke dinding saat terakhir dengan masalah memori Drupal. Inilah pengetahuan saya tentang topik ini:

1. Tampilan (dapat) menggunakan banyak memori

Saya suka saya beberapa Views (dan Panel dan CTools dan semuanya menyentuh merlinofchaos dengan jari-jarinya yang perkasa), tetapi dimungkinkan untuk membuat konfigurasi dengan beberapa hubungan yang menggunakan banyak memori. Jika Anda menonaktifkan Tampilan Anda dan masalah memori hilang, kemungkinan tampilan yang dibangun dengan buruk menyebabkan masalah.

Apa yang harus dilakukan jika itu adalah Tampilan, dan Anda benar-benar membutuhkan Tampilan itu untuk berfungsi? Cobalah memasukkannya ke dalam kode (Melalui Eksportir Massal atau Fitur; lihat di bawah. Saya memiliki fungsionalitas seperti tampilan kode tangan untuk meningkatkan kinerja dengan sedikit keberhasilan) sebagai permulaan. Pemikiran lain adalah mengulang Tampilan dengan cara yang berbeda - jika pada akhirnya yang Anda dapatkan adalah istilah taksonomi, pastikan jenis Tampilan adalah Tampilan Taksonomi saat membuatnya; jangan membuat Tampilan Konten yang menggunakan hubungan untuk mendapatkan persyaratan taksonomi.

Bisa juga layak disebutkan di sini bahwa Panel juga seharusnya menggunakan banyak memori - saya belum benar-benar membandingkannya jadi tidak dapat mengkonfirmasi ini.

2. Memindahkan barang dari database ke kode adalah praktik yang sangat bagus

Butuh beberapa situs Drupal untuk menyadari hal ini, tetapi menjaga semua yang dibuat melalui UI dalam basis data (konfigurasi Views dan Panel khususnya) adalah praktik terburuk Drupal. Mengapa? Ini meningkatkan beban pada database dan tidak dapat dikendalikan versi. Poin pertama sangat bermasalah dalam hal penggunaan memori - alih-alih hanya memuat konten dari tampilan dari database, situs juga harus memuat komponen tampilan itu sendiri. Ini diperparah dengan bagaimana Drupal menggunakan tabel: dengan mengabstraksikan semuanya ke tingkat ke-n, setiap bit fungsi Drupal menggunakan tabel baru, menghasilkan beberapa permintaan bergabung dengan tabel bajillion bersama-sama. Ini memberi orang-orang Ilmu Komputer hernia (peringatan: tautan itu konyol), tetapi tidak dapat benar-benar dihindari dengan perangkat lunak yang modular dan ramah pengguna seperti halnya Drupal.

Solusinya? Gunakan Eksportir Massal (Termasuk dengan CTools) atau Fitur untuk mengemas bit kode yang saat ini berada di database sebagai kode modul.

3. Tema juga bisa memakan memori

Apakah tema Anda memiliki banyak file templat (yaitu, file dengan nama / templat /)? Jika demikian, memori dikonsumsi setiap kali salah satu file tersebut dimuat. Jika Anda membuat template khusus untuk mencegah bit Drupal agar tidak ditampilkan, cobalah:

  1. Mengubah izin sehingga bit tersebut tidak muncul untuk peran pengguna non-admin tertentu.
  2. Menggunakan CSS untuk menyembunyikan elemen.

Pilihan pertama jelas-jelas adalah apa yang ingin Anda lakukan untuk hal-hal yang memengaruhi keamanan - Anda tidak ingin menggunakan CSS untuk menyembunyikan tombol "edit" untuk pengguna tertentu, hanya dengan meminta mereka lalu menyembunyikannya melalui Firebug atau apa pun.

4. Jangan berlebihan dengan modul contrib

Walaupun terkadang situs membutuhkan banyak modul contrib, jangan berlebihan. Setiap modul yang diaktifkan (catatan: diaktifkan. Modul yang dinonaktifkan tidak menggunakan memori apa pun) menggunakan memori. Ini agak jelas, tetapi perlu diperhatikan.

5. VPS (kadang-kadang) bohong

Dalam pengalaman saya, beberapa perusahaan hosting yang tidak bermoral suka mencoba mendorong situs Drupal ke server VPS - mereka lebih mahal dan membebaskan ruang hosting bersama untuk situs web WordPress yang semakin banyak. Situasi ini diperburuk oleh kenyataan bahwa hosting sering tidak beriklan (Atau bahkan dengan sukarela memberi tahu Anda jika ditanya) berapa batas memori atas untuk hosting bersama.

Sayangnya, sering kali jika sebuah situs tidak berada di bawah lalu lintas yang padat dan masih macet, masalah ini mungkin lebih berkaitan dengan konfigurasi Drupal daripada yang lainnya. Mendorong pengguna ke VPS hanya membuat kekacauan air dan menambahkan lebih banyak variabel untuk ditangani (Apakah ini konfigurasi server? Konfigurasi PHP? Konfigurasi tamu VPS? Konfigurasi host VPS, bahkan?).

6. Ketika semuanya gagal, klon ke localhost dan kalahkan dengan tongkat

Ini adalah alasan besar mengapa orang menggunakan metodologi dev-staging-production dengan kontrol versi - ketika semuanya gagal, Anda dapat melakukan dump DB, git mengkloning situs ke server pengujian lokal dan kemudian secara acak mengacaukan situs di server pengujian tanpa khawatir tentang benar-benar merusak apa pun di server produksi.

Untuk masalah memori, ini biasanya berarti menonaktifkan modul satu per satu hingga menyebabkan masalah terekspos. Hal ini juga dapat mengarah ke masalah yang terkait dengan hosting - jika situs berjalan dengan baik pada instalasi lokal dengan memori yang disetel ke sesuatu yang masuk akal seperti 128MB, maka Anda tahu bahwa hosting Anda sedang retak.

tl; dr

Perasaan saya adalah chain_menu_access yang menyebabkan masalah. Coba nonaktifkan itu dan bersihkan cache, lihat apakah itu berfungsi.

Saya juga akan menambahkan jawaban ini karena saya memikirkan hal lain untuk dicoba ...


... dan itulah tepatnya hal yang saya harapkan ketika saya memberi hadiah untuk pertanyaan ini! Terutama 2. 110 rep untuk Anda pak yang baik :) Semoga ini akan menarik beberapa komentar yang berguna dari orang lain dengan pengalaman yang sedikit berbeda
user56reinstatemonica8

ps Saya pernah mendengar di berbagai tempat bahkan modul yang dinonaktifkan menggunakan sejumlah memori dalam mem-parsing file. Saya telah melihat orang mengatakan bahwa semua file php / inc dapat diurai dengan cara tertentu, meskipun itu tampaknya tidak benar (lebih mungkin hanya file info). Adakah ide jika ada kebenaran dalam hal ini?
user56reinstatemonica8

Keren Terimakasih! Saya cukup yakin memori Drupal cukup teliti saat memuat file - jika Anda menjalankan XHProf, jumlah panggilan untuk file_scan_directorymenggunakan memori yang cukup. Saya akan menguji beberapa hal dengan devel ini setelah untuk mengkonfirmasi itu.
aendrew

Jika modul yang dinonaktifkan menggunakan memori apa pun, itu cukup tidak substansial. Saya melihat berapa banyak memori yang dilaporkan oleh Devel sebelum dan sesudah menghapus modul - sementara refresh halaman setelah menghapus file menunjukkan lonjakan kecil (<1MB), kemudian kembali ke nilai pra-penghapusan tepat pada refresh berikutnya. Ini membuat saya percaya bahwa Drupal a. Memindai direktori modul saat boot untuk melihat apakah ada file .info baru b. Menambahkan detail modul ke systemtabelnya c. Memuat modul apa pun dengan entri bidang system.status diatur ke 1. Jika ada yang bisa mengkonfirmasi atau membantah ini, saya akan menghargainya.
aendrew

2

Anda dapat mencoba menempatkan profiler PHP seperti XHProf atau profiler bawaan Xdebug untuk memeriksa apa yang terjadi dalam permintaan.


Setelah Anda mengetahui bagian mana yang membutuhkan jumlah memori yang telah Anda lakukan langkah 1. Langkah 2 adalah tentang mencoba memahami mengapa menggunakan banyak memori dan cara menguranginya. Orang-orang di atas berbicara tentang banyak hal dalam hasil dll. Secara umum itu adalah proses yang tidak dapat dijelaskan dengan mudah.
Daniel Wehner

1

Tampilan adalah babi memori. Caching Drupal dapat membantu. Namun Drupal hanya memuat modul yang aktif jika mereka membuat tabel atau memiliki objek lain yang dapat digunakan. Hanya menghapus instalan akan menghapus sebagian besar artefak. Kami menggunakan otorisasi / izin drupal dan menulis modul kami sendiri di dalamnya. Bukan yang terbaik tetapi kinerjanya jauh lebih baik dan lebih mudah disetel. Kami melakukan hal yang sama untuk WP juga.


0

Saya kasus masalah batas memori dihasilkan oleh sistem cache (Boost dan Boost Expire modules). Ini memberi saya masalah untuk memperbarui modul atau tampilan. Sekali dinonaktifkan, modul Boost semuanya bekerja dengan baik.

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.