Trang web trực tiếp trống ở lối vào hoặc tiếp tục tải và không bao giờ tải

Tôi đang đối mặt với vấn đề kỳ lạ nhất từng có trong magento. chúng tôi đang sử dụng phiên bản 1.9.0.

từ 2 tháng trước, trang web trực tiếp của chúng tôi "trống" hoặc "tiếp tục tải" cho các trình duyệt đã sử dụng. Có nghĩa là trong trình duyệt này, chúng tôi đã truy cập trang web rất nhiều lần.

trong một số trình duyệt, nó hoạt động tốt. trong một số hiển thị trống.

nhưng phụ trợ đang hoạt động tốt trong tất cả các trình duyệt.

chúng tôi đang phải đối mặt với vấn đề về chrome, mozilla, opera và tất cả các trình duyệt khác.

1) Nếu chúng tôi xóa lịch sử trình duyệt [bộ nhớ cache và cookie], thì nó sẽ hoạt động.

2) Nếu chúng ta mở cùng một trang trong cửa sổ riêng, nó sẽ hoạt động.

3) Nếu chúng tôi mở trang web trong các trình duyệt được cài đặt mới, nó sẽ hoạt động được một thời gian. lại trống sau khi chúng tôi sử dụng trang web.

4) Nếu chúng tôi xóa thư mục var / session, nó sẽ bắt đầu hoạt động cho tất cả các trình duyệt trong một thời gian. một lần nữa trang web trống.

5) đôi khi, trang web sẽ tiếp tục tải và nó sẽ không bao giờ tải ....

Tôi đã kiểm tra system.log & ngoại lệ.log . nhưng dường như không có lỗi liên quan đến điều này. chúng tôi đang sử dụng https cho các trang an toàn . thậm chí chúng tôi có ứng dụng Andriod trực tiếp cho trang web này. đôi khi chúng ta sẽ nhận được các lỗi nghiêm trọng:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

chúng tôi đặt memory_limit = 1512 Mb trong php.ini

trong .htaccess chúng tôi có các tệp sau.

Bộ nhớ php_value_limit 1512M php_value max_execut_time 18000

chúng tôi không chú ý điều này:

ini_set('display_errors', 1);

nhưng không có lỗi hiển thị ở frontend. Đây là nhật ký lỗi apache :

pid con tín hiệu thoát 23845 Lỗi phân đoạn (11), có thể bị cắt trong / etc / apache2

Thực sự đấu tranh để giải quyết vấn đề này. Vấn đề này có liên quan đến mã của chúng tôi hay vấn đề này liên quan đến phía máy chủ?

cookie trình duyệt là vấn đề chính? Nếu vậy cần phải làm gì để giải quyết vấn đề cookie này cho tất cả các trình duyệt. Tại sao nó bắt đầu hoạt động khi chúng tôi xóa thư mục phiên?

chúng tôi phải đối mặt với những vấn đề này khi duyệt trang web của chúng tôi.

Trước tiên hãy bật chế độ Nhà phát triển trong .htaccesstệp của bạn , thêm phần sau vào cuối tệp:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

Chỉnh sửa tiếp theo index.phpvà bỏ ghi chú dòng:

#ini_set('display_errors', 1);

Dòng tham chiếu:

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/index.php#L73

Đăng nhập tiếp theo qua SSH và tìm kiếm một tệp kết xuất lõi dưới đây /tmplà lỗi lỗi phân đoạn được đề cập. Đôi khi nó cũng có thể nằm trong thư mục gốc /hoặc trong thư mục gốc của chính trang web chẳng hạn : /var/www/html/videomergerapp/.

Nếu bạn không thể định vị bất kỳ tệp kết xuất lõi nào, bạn có thể muốn thêm một số chỉ thị bổ sung vào PHP / Apache.

Hãy xem ở đây:

• /server/470407/how-to-get-a-core-dump-from-apache-when-segfaulting
• http://www.cyberciti.biz/tips/configure-apache-web-server-for-core-dump.html

Khi bạn có (các) tệp kết xuất lõi, bạn có thể sử dụng gdb(nếu --enable-debug) được sử dụng khi PHP được định cấu hình. Bạn có thể đưa ra quyết định này bằng cách đưa ra những điều sau đây từ Dòng lệnh:

php -i | grep debughoặc chỉ đơn giản là tạo tệp tập lệnh php trong thư mục gốc máy chủ web của bạn với: <?php phpinfo(); ?>trong nội dung của nó và xem tệp qua trình duyệt web để xem các giá trị cấu hình PHP.

• https://bugs.php.net/bugs-generating-backtrace.php

Nếu nó không được kích hoạt, thì bạn sẽ không thể có được một backtrace đầy đủ vào chính PHP mà chỉ có các cuộc gọi hệ thống cấp cao hơn và / hoặc backtrace apache:

Nếu bạn có quyền truy cập vào tệp kết xuất lõi, việc phát hành một cái gì đó như sau sẽ cung cấp cho bạn một nền tảng để giúp tìm ra điểm thất bại:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027

Nếu bạn chỉ gặp các vấn đề ngẫu nhiên trên frontend và không bao giờ là phụ trợ, thì hầu hết các dấu hiệu đều chỉ ra một vấn đề có thể xảy ra với mã hóa mẫu của bạn. Khi bạn trải nghiệm các trang trống (và / hoặc hiển thị lỗi nếu bạn đã bật chế độ nhà phát triển và hiển thị lỗi). Đăng nhập vào quản trị viên của bạn và vô hiệu hóa tất cả bộ nhớ cache và xóa tất cả bộ nhớ cache và bộ nhớ cache.

Sau đó đi vào app/etc/local.xmlvà thiết lập các mô đun cục bộ vô hiệu thành đúng.

<disable_local_modules>true</disable_local_modules>

Điều này sẽ vô hiệu hóa trình tải tự động khỏi tải bất kỳ mô-đun nào app/code/local.

Để vô hiệu hóa các mô-đun cộng đồng, cách dễ nhất là đi qua từng tệp định nghĩa mô-đun của bạn được tìm thấy app/etc/modulesvà vô hiệu hóa bằng cách đặt nút hoạt động thành sai như vậy:

<active>false</active>

Bằng cách này, bạn có thể giúp loại trừ nếu mô-đun của bên thứ 3 gây ra nguồn gốc của vấn đề theo quá trình loại bỏ. LƯU Ý: Bạn không thể disable_local_modulesvà chỉ đơn giản là đi qua tất cả các mô-đun NON-CORE của mình (bất cứ điều gì Mage_ * bỏ qua!).

Nếu vẫn còn sự cố thì tôi sẽ thử gói gói mặc định tạm thời bằng cách đi tới Hệ thống> Thiết kế và xác định thiết kế mới của một cái gì đó như mặc định hoặc cơ sở. Nếu các gói mẫu chứng khoán hoạt động thì bạn sẽ biết nguyên nhân lỗi xảy ra trong các tệp thiết kế mẫu của bạn (.phtml).

Rất nhiều mẫu mà tôi gặp phải rất tệ khi sử dụng Mage::getModel()->load()trong các vòng lặp foreach vì đây là cách thực hành tồi và cuối cùng có thể tiêu thụ một lượng lớn bộ nhớ máy chủ và tài nguyên.

Magento có công cụ Phân tích mã có thể giúp quét các tệp mẫu của bạn để xác định xem có bất kỳ đoạn mã xấu nào sau đây không:

• https://github.com/magento-ecg/magniffer

Đọc thêm:

• Nguyên tắc cơ bản để gỡ lỗi một cửa hàng Magento

Ngoài ra, nó có thể hữu ích cho mọi người về bộ nhớ cache và lưu trữ phiên bạn đang sử dụng được xác định trong app/etc/local.xml.

Hi vọng điêu nay co ich!

Tôi đoán là có một đệ quy trong mã của bạn. Chỉnh sửa tập tin lib/Varien/Db/Adapter/Pdo/Mysql.phpvà thiết lập $_debugvà $_logCallStackthành đúng. Điều này sẽ ghi lại ngăn xếp cuộc gọi trong var/debug/pdo_mysql.logtệp sẽ cung cấp cho bạn một ý tưởng nếu có một đệ quy trong mã của bạn khi phải tải mãi mãi. Lưu ý rằng tệp này sẽ tiếp tục phát triển rất nhanh vì vậy lý tưởng cho phép nó khi bạn nghĩ rằng vấn đề đã bắt đầu trên trang web.

Một cách khác là vô hiệu hóa các mô-đun / tiện ích mở rộng có lỗi mà bạn nghĩ có thể gây ra điều này. Đây cũng có thể là phần mở rộng giá có thể định cấu hình đơn giản của bạn, hãy thử tắt nó tạm thời và xem liệu nó có giúp ngăn chặn sự cố không.

Tôi đã có cùng một vấn đề trong một trang web của khách hàng. Kiểm tra Magento của bạn cho phần mềm độc hại.

Đây là một kịch bản nổi tiếng, thông thường, nó là một phần mềm wal chuyển hướng nội dung bài đăng của người dùng sang một trang web bên ngoài.

Bắt đầu kiểm tra index.php, họ thường hack nó. Cuộn mã cho đến khi kết thúc, cũng kiểm tra bên phải và giữa các dòng nhận xét trong tiêu đề giấy phép. Tin tặc được sử dụng để ẩn mã theo cách này.

Bạn có "tải mãi mãi" vì nó cố gắng liên hệ với các trang web mà ISP của bạn bị chặn.

Nó khá dễ dàng để tìm phần mềm độc hại, tìm kiếm các chuỗi "base64", "eval", "mcrypt".

Tôi đã trải qua một hành vi tương tự trên một Magento có hai trang web. Trang web đã tải tốt trong một vài trang và sau đó tải mãi mãi.

Cấu hình của các URL cơ sở đã sai. Cài đặt URL Cơ sở Bảo mật được đặt thành trang web sai trong khi URL Cơ sở không bảo mật được đặt chính xác.

Vì vậy, để khắc phục điều này nếu quản trị viên thậm chí không hoạt động chính xác, các giá trị cần được thay đổi trong bảng core_config_data cho trang web bên phải, tức là đặt URL đúng với "http: //" và dấu gạch chéo trong trường giá trị tương ứng với đường dẫn "web / unsecure / base_url" và "web / safe / base_url" cho scope_id bên phải đại diện cho ID trang web.

Lưu ý rằng url bảo mật chỉ là http vì đây là trang web demo.