Cron fatal error insufficient shared memory

Проблемы с агентами cron

Добрый день!
Сайт на Битрикс распологается на сотинге reg.ru
У фрилансеров заказали подсайты для регионов. После этого начались проблемы на основном сайте с планировщиком.

При выполнении задачи
/opt/php/7.2-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
в планировщике возникает ошибка

u0111111$ /opt/php/7.0-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
PHP Warning: require_once(/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php): failed to open stream: No such file or directory in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10
PHP Fatal error: require_once(): Failed opening required ‘/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php’ (include_path=’.:’) in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10

на 2 подсайтах теже самые задачи выполняются без проблем.
Скрипты полностью идентичны, т.к. подсайты были полностью скопированы с основного.

В поддержке регру сначало посоветовали:
«Сравнили скрипты, различий не выявлено. Как мы можем видеть ,сейчас tlt.site.ru добавлен как автоподдомен для site.ru. Учитывая особенности CMS Битрикс, которая некорректно работает с автоподдоменами, мы рекомендуем добавить tlt.site.ru как отдельный www-домен и проверить актуальность проблемы.»

Но это результатов не дало. После этого они открестились:
«Как уже сообщалось ранее проблем со стороны хостинга не наблюдаем. Задание в планировщике написано корректно. Вопрос диагностики работы скриптов сайта выходит за рамки услуг, оказываемых специалистами технической поддержки хостинга. Для решения подобного вопроса мы рекомендуем вам обратиться к специалистам, которые занимались разработкой вашего сайта. Кроме того, интересующую вас информацию вы можете найти на тематических ресурсах, посвящённых разработке используемой вами CMS.»

Источник

I am running LAMP in VBox6.1 with Ubnutu Server 20.04.

Cause
This morning I removed all attachments to my vdi (optical disk & shared folders) and then used vboxmanage to —compact my vdi as recommended. (Compacting may be the cause of the problem or a bad php update.)

Problem
In any case, after reattaching my shared folders and rebooting my vdi, I was greeted by

Troubleshooting
I figured a bad php update knocked out apcu and redis so I ran: apt install —reinstall php8.0-apcu && apt install —reinstall php8.0-redis and this solved two parts of my problem.

However, I am currently stuck with this error:

Useful Info

• All other versions of php-fpm are working correctly
• Attempting to reinstall php8.0-fpm results i the same problem
• The are zero limits on my shared memory:
• # sysctl -a | grep kernel.shm

• I booted from LiveCD and ran e2fsck -cfyv /dev/mapper/vgubuntu-vg (no errors)
• The php8.0 php.ini confirms that shared memory is configured properly:

I also considered that maybe another application was consuming allof the shared memory and causing php8.0-fpm to fail. not the case:

So at this point, I am stumped. 🤔🤔🤔

Question:
How do I get php8.0-fpm-running again?

Источник

Fatal Error Zend OPcache cannot allocate buffer for interned strings #2293

Creating a bug report/issue:

Cannot install any software after 6.18 update.

Required Information:

• DietPi version | cat /DietPi/dietpi/.version

• Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version

• Kernel version | uname -a

Linux DietPi 4.14.78-sunxi #412 SMP Fri Oct 26 11:37:04 CEST 2018 armv7l GNU/Linux

• SBC device | echo $G_HW_MODEL_DESCRIPTION or (EG: RPi3)

OrangePi Zero (armv7l)

• Power supply used | (EG: 5V 1A RAVpower)

• SDcard used | (EG: SanDisk ultra)
  EMTEC 16GB, class 10

Additional Information (if applicable):

• Software title | (EG: Nextcloud)
  Any
• Was the software title installed freshly or updated/migrated?
  Fresh
• Can this issue be replicated on a fresh installation of DietPi?
  I don’t know
• dietpi-bugreport ID
  9444d4b6-b4e7-4096-9996-a532804506cf

Steps to reproduce:

1. For instance try to install LinuxDash
   sudo dietpi-software install 63

Expected behaviour:

• Install the software and reboot

Actual behaviour:

Tue Nov 27 00:11:50 2018 (4528): Fatal Error Zend OPcache cannot allocate buffer for interned strings
/DietPi/dietpi/dietpi-software: line 7469: / 1024 / 1024: syntax error: operand expected (error token is «/ 1024 / 1024»)

• Also this error somewhere in between:

Tue Nov 27 00:32:17 2018 (6687): Fatal Error Zend OPcache cannot allocate buffer for interned strings

The text was updated successfully, but these errors were encountered:

@Twilight0
Thanks for your report.

The command that fails is: php -r ‘print(PHP_INT_MAX);’
Works well here on VirtualBox Stretch and dietpi-software install 63 went through without error:

Fatal Error Zend OPcache cannot allocate buffer for interned strings

Something with PHP OPcache module seems to be broken.

OPcache can be configured via: opcache.interned_strings_buffer in php.ini / opcache.ini . The only case where we touch this is on Nextcloud install. But using the value we add there opcache.interned_strings_buffer=8 works well here as well. Default is 4 .

Can you check if/where you set this value:
grep ‘opcache.interned_strings_buffer’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini

Possibly a reinstall of the OPcache module will fix: apt-get -y install —reinstall php7.0-opcache

I am sorry but I get frustrated easily sometimes and re-installed DietPi from scratch. I ‘ll provide report if necessary from the fresh install or close and comment it if everything is fine.

I will close this issue as it looks like it is ok on fresh installations. I had tweaked something according to this comment when tried to installed nextcloud on 6.17, probably something broke: #2192 (comment)

Reopening this issue. yeah I tried installing nextcloud once again since you claim it has been fixed for 6.18.
And it failed gloriously with the same error. And yes I tried this after re-installing php7.0-opcache.

So this is the output of grep ‘opcache.interned_strings_buffer’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini :

/etc/php/7.0/cli/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/fpm/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/mods-available/opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/phpdbg/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/cli/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/fpm/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/phpdbg/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8

@Twilight0
Thanks for testing. Jep this issue is a different one than: #2192 (comment)

We will have to do some research about when/why this issue can occur. I am stuck currently since everything looks as expected.

Just, because this is the only place where we touch OPcache settings, can you try to comment all opcache.* lines inside /etc/php/7.0/mods-available/opcache.ini (not the one that loads the module itself, just the settings. Comment them with ; .
Then:

and see if the error still shows up (with default settings then).

https://forums.zend.com/viewtopic.php?t=113253
memory_limit , must this in case be as large as opcache.memory_consumption + opcache.interned_strings_buffer , so being an overall limit? But actually no chance to hit that with Nextcloud 🤔 .

@Twilight0
Okay some more to check, going through the memory limits and consumptions:

And you can also check the actual PHP memory consumption of OPcache and APCu:

Ah just saw you sent a bug report. I will also go through it there.

Issue appears limited to this device + pre-image. Could be a PREP issue (unlikely if everything else is working fine)

Which pre-image/image did you use for the OPi Zero?

Armbian’s one. Stable PREP script & stable Dietpi release. Will report back when I have time to test things out.

@Twilight0
Could you please paste the output of above mentioned commands? If all this is as expected, perhaps there is a sysctl.conf/sysctl.d/*.conf entry that somehow limits memory allocation. Not sure what’s possible there.
And could you send a bug report?

But perhaps it’s easiest of @Fourdee can try to replicate, if you have a OPi Zero there? Even it is an issue with a non-officially supported device, perhaps there is some setting outside of PHP that causes this issue that we then need to check/adjust on PHP install.

grep ‘memory_limit’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini

/etc/php/7.0/cli/php.ini:memory_limit = -1
/etc/php/7.0/fpm/php.ini:memory_limit = 128M
/etc/php/7.0/phpdbg/php.ini:memory_limit = 128M

grep ‘opcache.memory_consumption’ /etc/php/7.0/*/*.ini /etc/php/7.2/*/*/*.ini

/etc/php/7.0/cli/php.ini:;opcache.memory_consumption=64
/etc/php/7.0/fpm/php.ini:;opcache.memory_consumption=64
/etc/php/7.0/mods-available/opcache.ini:opcache.memory_consumption=10
/etc/php/7.0/phpdbg/php.ini:;opcache.memory_consumption=64
grep: /etc/php/7.2///*.ini: No such file or directory

grep ‘apc.shm_size’ /etc/php/7.0/*/*.ini /etc/php/7.2/*/*/*.ini

/etc/php/7.0/mods-available/apcu.ini:apc.shm_size=10M
grep: /etc/php/7.2///*.ini: No such file or directory

Filesystem 1K-blocks Used Available Use% Mounted on
udev 87112 0 87112 0% /dev
tmpfs 24580 4592 19988 19% /run
/dev/mmcblk0p1 14905760 3211112 11517444 22% /
tmpfs 122888 0 122888 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 122888 0 122888 0% /sys/fs/cgroup
/dev/sdb1 3658611 26655 3432225 1% /mnt/flash
/dev/sda1 976760532 749137600 227622932 77% /mnt/toshiba
tmpfs 1047552 0 1047552 0% /tmp
tmpfs 10240 1476 8764 15% /DietPi
tmpfs 51200 120 51080 1% /var/log

total used free shared buff/cache available
Mem: 240 65 58 13 116 153
Swap: 1807 0 1807

However these are after clean install plus a few things without Nextcloud marked, because in case I try installing Nextcloud, it will ruin the system with ncc maintenance error messages etc.

Details:

• Date | Mon 4 Feb 04:37:16 CET 2019
• Bug report | N/A
• DietPi version | v6.20.6 (Fourdee/master)
• Img creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi 3 Model A+ (armv7l) (index=3)
• Kernel version |

Letsencrypt supports Free Noip.com Dynamic DNS #1159 SMP Sun Nov 4 17:50:20 GMT 2018

Steps to reproduce:

1. Install Nextcloud through dietpi-software .

Expected behaviour:

Actual behaviour:

• Installation interrupts with error.

• Selected Nextcloud to be installed from dietpi-software . DietPi was freshly set up, nothing was on storage, yet.

Additional logs:

Log file contents:
Mon Feb 4 04:35:56 2019 (22158): Fatal Error Zend OPcache cannot allocate buffer for interned strings

No OPi specific issue then. @Akito13 could you please as well paste the outputs as mentioned above: #2293 (comment)

Nothing to do with your application that I don’t know, however, I’m confronted with this bug.

Indeed, I have a firewall in VM Pfsense that runs with 256Mb, if I pass it to 512MB of RAM, I have the error mentioned.

@jbsky
Thanks for sharing.

Possibly this error can occur on low RAM systems (256M) if the PHP/OPcache memory limits exceed available (or free?) RAM.

Strange is that the error states the interned strings buffer allocation to fail, since this one is very small (4M default, 8M as we set on Nextcloud install due to admin panel warnings/recommendation).
What should fail in the first place is the overall OPcache memory limit which is 128M by default since PHP7.0.

And you say if you set overall PHP memory limit from 512M (default on Debian) to 256M, it does not occur? Even more strange.

I will play around with a 256M memory VM as well and try to replicate.

I ran into this same issue @MichaIng and you are correct it will throw this error on low RAM systems that use more than the actually amount available.

I have an application that I cranked the instance size up and adjusted opcache.memory_consumption. Friday I turned it back down as there is no traffic over the weekend and came into that error.

I actually didn’t adjust the PHP memory limit for itself. Just the opcache memory consumption so that may help some in tracking it down.

Okay I reopen this to not forget the testing on VM. We’ll see if it depends on total memory, free memory and if total PHP memory limit has any effect.

Hmm just got on fresh 1 GiB RAM Buster VirtualBox machine:

The PHP memory limit is below the recommended value of 512MB.

The following then solves the warning:

Since we do not touch this value, it’s Debian Buster package default:

Strange that I never faced this before. New on Nextcloud side? Would be a real problem since low RAM devices (RPi1 with 256M) are perfectly able to run a single user or family Nextcloud instance and should never set memory_limit > 128M of course.

Okay, I ran some tests and was able to produce the following error on PHP-FPM start/restart:

Basically this appears in two cases:

1. The virtual memory of any PHP child process exceeds the available system memory, including swap files, minus a few megabytes.

• The assigned opcache.memory_consumption increases the virtual memory usage 1-to-1.
• The assigned opcache.interned_strings_buffer has no effect on virtual memory usage, it seems to be included in the overall OPcache memory consumption.
• memory_limit as well has no influence, also I think the border at which those are active, are different. opcache.memory_consumption limits the overall OPcache consumption, as it’s virtual/shared memory, across all PHP-FPM child processes, I guess, while memory_limit is a per-script limit.

1. opcache.interned_strings_buffer is equal or larger than opcache.memory_consumption .

• This fits the above assumption that opcache.interned_strings_buffer is included in opcache.memory_consumption .
• However default values and those applied by us on Nextcloud installs provide a every large difference between the two sizes (default: 128 vs 4, DietPi + Nextcloud: 512 vs 8), hence this cannot be a reason. EDIT: Confused with memory_limit

If I reduce system memory or raise memory usage by other processes, while keeping the above rules, I run into usual OOM killer.

Источник

Добрый день!
Сайт на Битрикс распологается на сотинге reg.ru
У фрилансеров заказали подсайты для регионов. После этого начались проблемы на основном сайте с планировщиком.

При выполнении задачи
/opt/php/7.2-bx-optimized/bin/php -c ~/php-bin/php.ini -f ~/www/site.ru/bitrix/modules/main/tools/cron_events.php
в планировщике возникает ошибка

u0111111$ /opt/php/7.0-bx-optimized/bin/php -c ~/php-bin/php.ini -f ~/www/site.ru/bitrix/modules/main/tools/cron_events.php
PHP Warning:  require_once(/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php): failed to open stream: No such file or directory in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10
PHP Fatal error:  require_once(): Failed opening required ‘/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php’ (include_path=’.:’) in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10

на 2 подсайтах теже самые задачи выполняются без проблем.
Скрипты полностью идентичны, т.к. подсайты были полностью скопированы с основного.

В поддержке регру сначало посоветовали:
«Сравнили скрипты, различий не выявлено. Как мы можем видеть ,сейчас tlt.site.ru добавлен как автоподдомен для site.ru. Учитывая особенности CMS Битрикс, которая некорректно работает с автоподдоменами, мы рекомендуем добавить tlt.site.ru как отдельный www-домен и проверить актуальность проблемы.»

Но это результатов не дало. После этого они открестились:
«Как уже сообщалось ранее проблем со стороны хостинга не наблюдаем. Задание в планировщике написано корректно. Вопрос диагностики работы скриптов сайта выходит за рамки услуг, оказываемых специалистами технической поддержки хостинга. Для решения подобного вопроса мы рекомендуем вам обратиться к специалистам, которые занимались разработкой вашего сайта. Кроме того, интересующую вас информацию вы можете найти на тематических ресурсах, посвящённых разработке используемой вами CMS.»

Заранее благодарю за помощь!

1С-Битрикс: Управление сайтом 17.5.16.

I am running LAMP in VBox6.1 with Ubnutu Server 20.04.

Cause
This morning I removed all attachments to my vdi (optical disk & shared folders) and then used vboxmanage to --compact my vdi as recommended. (Compacting may be the cause of the problem or a bad php update.)

Problem
In any case, after reattaching my shared folders and rebooting my vdi, I was greeted by

● php8.0-fpm.service loaded failed failed The PHP 8.0 FastCGI Process Manager
...
Starting The PHP 8.0 FastCGI Process Manager...
php-fpm8.0[5192]: [15-Jan-2023 07:41:57] NOTICE: PHP message: PHP Warning:  PHP Startup: Unable to load dynamic library 'apcu.so' (tried: /usr/lib/php/20200930/apcu.so (/usr/lib/php/20200930/apcu.so: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/apcu.so.so (/usr/lib/php/20200930/apcu.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
php-fpm8.0[5192]: [15-Jan-2023 07:41:57] NOTICE: PHP message: PHP Warning:  PHP Startup: Unable to load dynamic library 'redis.so' (tried: /usr/lib/php/20200930/redis.so (/usr/lib/php/20200930/redis.so: cannot open shared object file: No such file or directory), /usr/lib/php/20200930/redis.so.so (/usr/lib/php/20200930/redis.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
php-fpm8.0[5192]: Sun Jan 15 07:41:57 2023 (5192): Fatal Error Insufficient shared memory!
php8.0-fpm.service: Main process exited, code=exited, status=254/n/a
php8.0-fpm.service: Failed with result 'exit-code'.
ystemd[1]: Failed to start The PHP 8.0 FastCGI Process Manager.
....

Troubleshooting
I figured a bad php update knocked out apcu and redis so I ran: apt install --reinstall php8.0-apcu && apt install --reinstall php8.0-redis and this solved two parts of my problem.

However, I am currently stuck with this error:

● php8.0-fpm.service loaded failed failed The PHP 8.0 FastCGI Process Manager
...
Starting The PHP 8.0 FastCGI Process Manager...
php-fpm8.0[4226]: Sun Jan 15 08:39:51 2023 (4226): Fatal Error Insufficient shared memory!
php8.0-fpm.service: Main process exited, code=exited, status=254/n/a
php8.0-fpm.service: Failed with result 'exit-code'.
Failed to start The PHP 8.0 FastCGI Process Manager.
...

Useful Info

• All other versions of php-fpm are working correctly
• Attempting to reinstall php8.0-fpm results i the same problem
• The are zero limits on my shared memory:
• # sysctl -a | grep kernel.shm

    kernel.shm_next_id = -1
    kernel.shm_rmid_forced = 0
    kernel.shmall = 18446744073692774399
    kernel.shmmax = 18446744073692774399
    kernel.shmmni = 4096

• I booted from LiveCD and ran e2fsck -cfyv /dev/mapper/vgubuntu-vg (no errors)
• The php8.0 php.ini confirms that shared memory is configured properly:

root@test:~# php8.0 -i | grep -i sysvshm
/etc/php/8.0/cli/conf.d/20-sysvshm.ini,
sysvshm
sysvshm support => enabled
root@test:~# php8.0 -i | grep -i sysvsem
/etc/php/8.0/cli/conf.d/20-sysvsem.ini,
sysvsem
sysvsem support => enabled
root@test:~# php8.0 -i | grep -i sysvmsg
/etc/php/8.0/cli/conf.d/20-sysvmsg.ini,
sysvmsg
sysvmsg support => enabled
root@test:~# php8.0 -i | grep -i shmop
/etc/php/8.0/cli/conf.d/20-shmop.ini,
shmop
shmop support => enabled

I also considered that maybe another application was consuming allof the shared memory and causing php8.0-fpm to fail… not the case:

# ipcs -m --human

------ Shared Memory Segments --------
key        shmid      owner      perms      size       nattch     status      
0x64000630 4          root       600          1.1M     4                     

So at this point, I am stumped. 🤔🤔🤔

Question:
How do I get php8.0-fpm-running again?

Comments

+ DietPi-Software | PHP: Move session files to tmpfs outside of /tmp and /var/tmp to /run/php_sessions by default
+ DietPi-Software | PHP: Move tmp upload dir back to tmpfs but limit default max upload size, discuss and find balance between performance, disk (SD card) writes and RAM over-usage.
+ DietPi-Software | PHP: Assure that opcache.interned_strings_buffer is never larger than half of opcache.memory_consumption: #2293
+ DietPi-Software | ownCloud/Nextcloud: On <1 GiB devices assure at least 512 MiB swap space are available to stand 512 MiB file uploads + increased PHP cache and session file usage

Проблемы с агентами cron

Добрый день!
Сайт на Битрикс распологается на сотинге reg.ru
У фрилансеров заказали подсайты для регионов. После этого начались проблемы на основном сайте с планировщиком.

При выполнении задачи
/opt/php/7.2-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
в планировщике возникает ошибка

u0111111$ /opt/php/7.0-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
PHP Warning: require_once(/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php): failed to open stream: No such file or directory in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10
PHP Fatal error: require_once(): Failed opening required ‘/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php’ (include_path=’.:’) in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10

на 2 подсайтах теже самые задачи выполняются без проблем.
Скрипты полностью идентичны, т.к. подсайты были полностью скопированы с основного.

В поддержке регру сначало посоветовали:
«Сравнили скрипты, различий не выявлено. Как мы можем видеть ,сейчас tlt.site.ru добавлен как автоподдомен для site.ru. Учитывая особенности CMS Битрикс, которая некорректно работает с автоподдоменами, мы рекомендуем добавить tlt.site.ru как отдельный www-домен и проверить актуальность проблемы.»

Но это результатов не дало. После этого они открестились:
«Как уже сообщалось ранее проблем со стороны хостинга не наблюдаем. Задание в планировщике написано корректно. Вопрос диагностики работы скриптов сайта выходит за рамки услуг, оказываемых специалистами технической поддержки хостинга. Для решения подобного вопроса мы рекомендуем вам обратиться к специалистам, которые занимались разработкой вашего сайта. Кроме того, интересующую вас информацию вы можете найти на тематических ресурсах, посвящённых разработке используемой вами CMS.»

Источник

Проблемы с агентами cron

Добрый день!
Сайт на Битрикс распологается на сотинге reg.ru
У фрилансеров заказали подсайты для регионов. После этого начались проблемы на основном сайте с планировщиком.

При выполнении задачи
/opt/php/7.2-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
в планировщике возникает ошибка

u0111111$ /opt/php/7.0-bx-optimized/bin/php -c

/www/site.ru/bitrix/modules/main/tools/cron_events.php
PHP Warning: require_once(/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php): failed to open stream: No such file or directory in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10
PHP Fatal error: require_once(): Failed opening required ‘/var/www/u0111111/data/www/sbx15.hosting.reg.ru:1500/bitrix/modules/main/start.php’ (include_path=’.:’) in /var/www/u0111111/data/www/site.ru/bitrix/modules/main/include.php on line 10

на 2 подсайтах теже самые задачи выполняются без проблем.
Скрипты полностью идентичны, т.к. подсайты были полностью скопированы с основного.

В поддержке регру сначало посоветовали:
«Сравнили скрипты, различий не выявлено. Как мы можем видеть ,сейчас tlt.site.ru добавлен как автоподдомен для site.ru. Учитывая особенности CMS Битрикс, которая некорректно работает с автоподдоменами, мы рекомендуем добавить tlt.site.ru как отдельный www-домен и проверить актуальность проблемы.»

Но это результатов не дало. После этого они открестились:
«Как уже сообщалось ранее проблем со стороны хостинга не наблюдаем. Задание в планировщике написано корректно. Вопрос диагностики работы скриптов сайта выходит за рамки услуг, оказываемых специалистами технической поддержки хостинга. Для решения подобного вопроса мы рекомендуем вам обратиться к специалистам, которые занимались разработкой вашего сайта. Кроме того, интересующую вас информацию вы можете найти на тематических ресурсах, посвящённых разработке используемой вами CMS.»

Источник

Общий форум

Не запускается purge_caches.php

Не запускается purge_caches.php

Добрый день, уважаемые форумчане! При попытке создания запланированной задачи запуска скрипта чистки кэша purge_caches.php выдает ошибку Fri Jun 14 00:00:01 2019 (421226): Fatal Error Insufficient shared memory!. Cron работает в штатном режиме. Просьба подсказать в чем может быть проблема и где искать решение.

Re: Не запускается purge_caches.php

А зачем вы вообще скрипт purge_caches в Cron прописали? Это рекомендуется где-то в документации?

В планировщике достаточно задач по работе с кэшем: coretaskcache_cleanup_task, coretaskcache_cron_task и др. Зачем заниматься самодеятельностью?

Лучше cron.php настройте на запуск каждую минуту

Re: Не запускается purge_caches.php

Говоря начистоту, с moodle работаю совсем недавно, поэтому могу своими кривыми руками сделать что то не то. Изначально проблема стояла в том, что на хостинге росло количество объектов файловой системы и при достижения определенного порога сайт блокировали. После чистки кеша, количество файлов уменьшилось в разы. Исходя из этого решил попробовать добавить задание на очистку самостоятельно, в автоматизированном режиме. После конечно пожалел, в поддержке хостинга сделали корректировку команда, вследствии чего на сайту тупо перестали работать пункты меню, выпадающие списки и прочее. Для самого скрипта cron не страшно если он будет запускаться раз в минуту. Благодарю за ответ.

Re: Не запускается purge_caches.php

значит у вас не очень хороший хостинг — moodle создает в кэше очень много объектов. Обычно при жалобах на хостинг говорят, что мало памяти, ограничено время выполнения скрипта, но чтобы ограничивали число файлов в системе, такого не слышал.

Если ваш хостер предоставляет memcached или redis, можно перенастроить кэширование, тогда в файловой системе не будет много файлов кэша.

Cron по документации должен работать ежеминутно.

Источник

Bus error. Insufficient shared memory? #929

Comments

FishLikeApple commented Jul 4, 2019

Describe the bug
When workers_per_gpu>0 in the config file, the error will arise. I searched for some keywords of the error, only the way to set workers_per_gpu to 0 can work, I know it means to make data preparation and training serial, which was time-consuming.

Reproduction

1. What command or script did you run?

1. Did you make any modifications on the code or config? Did you understand what you have modified?
   I changed some part for suitability for another dataset.
   I commented out SyncBN (#norm_cfg=norm_cfg), because it designed for distributed training and I only had access to one GPU (P40) (please let me know if I can use SyncBN on a single GPU for a better result).
2. What dataset did you use?
   a small part of Open Images

Environment

• OS: [linux-x86_64]
• PyTorch version [3.5]
• How you installed PyTorch [pip]
• GPU model [P40]
  (the environment was on cloud and was’t set by me, I will be to find more accurate information if you need)

Error traceback

Bug fix
The memory was 15G with 2 CPUs. Insufficient shared memory? I’m not sure.

And thanks for your great work, I can already see improvement after some training, probably I will continuously use mmdetection for tasks with high accuracy requirements.

The text was updated successfully, but these errors were encountered:

FishLikeApple commented Jul 4, 2019

I’m sorry, PyTorch is lastest due to that it’s upgraded each time the environment starts.

FishLikeApple commented Jul 5, 2019

Is there anyone who can give any suggestion? Any suggestion will be great. Thank you.

FishLikeApple commented Jul 5, 2019

Ok, I think I have some clue, it seems that I misunderstood the framework.

FishLikeApple commented Jul 14, 2019

If I set workers_per_gpu>0, Pytorch will create a new worker on GPU, so the insufficient memory is of GPU I guess.
But still, I have some work to do to use multiple CPUs for preprocessing.

John-Yao commented Jul 18, 2019

you can try to use multi-dataset which are small parts of total dataset.
The mmcv.runner support multi-dataloaders. But the mmdetection don’t support it. There are some files to be modify:
1)mmdet/apis/train.py :
make multi-dataloader by build_dataloader in dist_train or no_dist train function.
2)mmdet/datasets/utils.py:
modify the func ‘get_dataset’ to return multi-dataset instead of Concatdataset
3) config file:
modify as below:
workflow = [(‘train’, 1)]
ann_file=[data_root + ‘jsons/train.json’],
->
workflow = [(‘train’, 1),(‘train’, 1),(‘train’, 1),(‘train’, 1)]
ann_file=[data_root + ‘jsons/train.json.part0’,data_root + ‘jsons/train.json.part1’,data_root + ‘jsons/train.json.part2’,data_root + ‘jsons/train.json.part3’]
Also the step and total epoch , interval of evaluation should be multipied by the num of trainsets

FishLikeApple commented Jul 18, 2019

you can try to use multi-dataset which are small parts of total dataset.
The mmcv.runner support multi-dataloaders. But the mmdetection don’t support it. There are some files to be modify:
1)mmdet/apis/train.py :
make multi-dataloader by build_dataloader in dist_train or no_dist train function.
2)mmdet/datasets/utils.py:
modify the func ‘get_dataset’ to return multi-dataset instead of Concatdataset
3) config file:
modify as below:
workflow = [(‘train’, 1)]
ann_file=[data_root + ‘jsons/train.json’],
->
workflow = [(‘train’, 1),(‘train’, 1),(‘train’, 1),(‘train’, 1)]
ann_file=[data_root + ‘jsons/train.json.part0’,data_root + ‘jsons/train.json.part1’,data_root + ‘jsons/train.json.part2’,data_root + ‘jsons/train.json.part3’]
Also the step and total epoch , interval of evaluation should be multipied by the num of trainsets

Thanks, now I’m considering using group normalization, with which I can use smaller batches to train, so it’s OK to use multiple workers in GPU.

FishLikeApple commented Jul 21, 2019

I have found some thing time-consuming, the log below is my training log.

2019-07-21 16:20:05,759 — INFO — Epoch [1][5231/30000] lr: 0.02000, eta: 4 days, 8:18:01, time: 2.013, data_time: 1.655, memory: 2677, loss_rpn_cls: 0.2121, loss_rpn_bbox: 0.0146, s0.loss_cls: 0.0523, s0.acc: 99.8047, s0.loss_bbox: 0.0000, s1.loss_cls: 0.0187, s1.acc: 99.8047, s1.loss_bbox: 0.0000, s2.loss_cls: 0.0094, s2.acc: 99.8047, s2.loss_bbox: 0.0000, loss: 0.3071
2019-07-21 16:20:07,772 — INFO — Epoch [1][5232/30000] lr: 0.02000, eta: 4 days, 8:19:04, time: 2.013, data_time: 1.595, memory: 2677, loss_rpn_cls: 0.4542, loss_rpn_bbox: 0.0583, s0.loss_cls: 0.4526, s0.acc: 94.1406, s0.loss_bbox: 0.0909, s1.loss_cls: 0.1520, s1.acc: 96.4844, s1.loss_bbox: 0.0344, s2.loss_cls: 0.0644, s2.acc: 97.4609, s2.loss_bbox: 0.0067, loss: 1.3134
2019-07-21 16:20:09,537 — INFO — Epoch [1][5233/30000] lr: 0.02000, eta: 4 days, 8:19:51, time: 1.764, data_time: 1.417, memory: 2677, loss_rpn_cls: 0.5243, loss_rpn_bbox: 0.1209, s0.loss_cls: 0.3645, s0.acc: 94.1406, s0.loss_bbox: 0.1174, s1.loss_cls: 0.0937, s1.acc: 97.2656, s1.loss_bbox: 0.0134, s2.loss_cls: 0.0489, s2.acc: 97.4609, s2.loss_bbox: 0.0060, loss: 1.2892
2019-07-21 16:20:11,213 — INFO — Epoch [1][5234/30000] lr: 0.02000, eta: 4 days, 8:20:32, time: 1.677, data_time: 1.298, memory: 2677, loss_rpn_cls: 0.2924, loss_rpn_bbox: 0.0663, s0.loss_cls: 0.0605, s0.acc: 99.8047, s0.loss_bbox: 0.0001, s1.loss_cls: 0.0230, s1.acc: 99.8047, s1.loss_bbox: 0.0000, s2.loss_cls: 0.0102, s2.acc: 99.8047, s2.loss_bbox: 0.0000, loss: 0.4525
2019-07-21 16:20:12,707 — INFO — Epoch [1][5235/30000] lr: 0.02000, eta: 4 days, 8:21:00, time: 1.493, data_time: 1.127, memory: 2677, loss_rpn_cls: 0.3955, loss_rpn_bbox: 0.1449, s0.loss_cls: 0.0590, s0.acc: 99.8047, s0.loss_bbox: 0.0001, s1.loss_cls: 0.0227, s1.acc: 99.8047, s1.loss_bbox: 0.0000, s2.loss_cls: 0.0102, s2.acc: 99.8047, s2.loss_bbox: 0.0000, loss: 0.6324
2019-07-21 16:20:13,987 — INFO — Epoch [1][5236/30000] lr: 0.02000, eta: 4 days, 8:21:14, time: 1.281, data_time: 0.945, memory: 2677, loss_rpn_cls: 0.3093, loss_rpn_bbox: 0.0630, s0.loss_cls: 0.0985, s0.acc: 99.0234, s0.loss_bbox: 0.0083, s1.loss_cls: 0.0344, s1.acc: 99.4141, s1.loss_bbox: 0.0012, s2.loss_cls: 0.0191, s2.acc: 99.4141, s2.loss_bbox: 0.0011, loss: 0.5350

One can see that data_time is a lot of time, it occupied a large part of time of each batch. Is data_time the time used to process data (get training images)? Thinks for all suggestions.

Pattorio commented Jul 29, 2019

Never set worker_per_gpu=0, or you will spend LOOOONG time for training.

Did you use docker? When you run docker, add —shm-size=»8g» or any size you need but more than 64M.

FishLikeApple commented Jul 29, 2019

Never set worker_per_gpu=0, or you will spend LOOOONG time for training.

Did you use docker? When you run docker, add —shm-size=»8g» or any size you need but more than 64M.

Thanks, I’m using a cloud plaform which provides a virtual Linux machine. Now I’m using batch size 1 with GN (it’s good to know that mmdetection has supported GN). I think technically GN doesn’t depend on batch size.

Источник

Fatal Error Zend OPcache cannot allocate buffer for interned strings #2293

Comments

Twilight0 commented Nov 26, 2018 •

Creating a bug report/issue:

Cannot install any software after 6.18 update.

Required Information:

• DietPi version | cat /DietPi/dietpi/.version

• Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version

• Kernel version | uname -a

Linux DietPi 4.14.78-sunxi #412 SMP Fri Oct 26 11:37:04 CEST 2018 armv7l GNU/Linux

• SBC device | echo $G_HW_MODEL_DESCRIPTION or (EG: RPi3)

OrangePi Zero (armv7l)

• Power supply used | (EG: 5V 1A RAVpower)

• SDcard used | (EG: SanDisk ultra)
  EMTEC 16GB, class 10

Additional Information (if applicable):

• Software title | (EG: Nextcloud)
  Any
• Was the software title installed freshly or updated/migrated?
  Fresh
• Can this issue be replicated on a fresh installation of DietPi?
  I don’t know
• dietpi-bugreport ID
  9444d4b6-b4e7-4096-9996-a532804506cf

Steps to reproduce:

1. For instance try to install LinuxDash
   sudo dietpi-software install 63

Expected behaviour:

• Install the software and reboot

Actual behaviour:

Tue Nov 27 00:11:50 2018 (4528): Fatal Error Zend OPcache cannot allocate buffer for interned strings
/DietPi/dietpi/dietpi-software: line 7469: / 1024 / 1024: syntax error: operand expected (error token is «/ 1024 / 1024»)

Extra details:

• Also this error somewhere in between:

Tue Nov 27 00:32:17 2018 (6687): Fatal Error Zend OPcache cannot allocate buffer for interned strings

The text was updated successfully, but these errors were encountered:

MichaIng commented Nov 26, 2018 •

@Twilight0
Thanks for your report.

The command that fails is: php -r ‘print(PHP_INT_MAX);’
Works well here on VirtualBox Stretch and dietpi-software install 63 went through without error:

Fatal Error Zend OPcache cannot allocate buffer for interned strings

Something with PHP OPcache module seems to be broken.

OPcache can be configured via: opcache.interned_strings_buffer in php.ini / opcache.ini . The only case where we touch this is on Nextcloud install. But using the value we add there opcache.interned_strings_buffer=8 works well here as well. Default is 4 .

Can you check if/where you set this value:
grep ‘opcache.interned_strings_buffer’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini

Possibly a reinstall of the OPcache module will fix: apt-get -y install —reinstall php7.0-opcache

Twilight0 commented Nov 26, 2018

I am sorry but I get frustrated easily sometimes and re-installed DietPi from scratch. I ‘ll provide report if necessary from the fresh install or close and comment it if everything is fine.

Twilight0 commented Nov 27, 2018

I will close this issue as it looks like it is ok on fresh installations. I had tweaked something according to this comment when tried to installed nextcloud on 6.17, probably something broke: #2192 (comment)

Twilight0 commented Nov 27, 2018 •

Reopening this issue. yeah I tried installing nextcloud once again since you claim it has been fixed for 6.18.
And it failed gloriously with the same error. And yes I tried this after re-installing php7.0-opcache.

So this is the output of grep ‘opcache.interned_strings_buffer’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini :

/etc/php/7.0/cli/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/fpm/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/mods-available/opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/phpdbg/php.ini:;opcache.interned_strings_buffer=4
/etc/php/7.0/cli/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/fpm/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8
/etc/php/7.0/phpdbg/conf.d/10-opcache.ini:opcache.interned_strings_buffer=8

MichaIng commented Nov 27, 2018

@Twilight0
Thanks for testing. Jep this issue is a different one than: #2192 (comment)

We will have to do some research about when/why this issue can occur. I am stuck currently since everything looks as expected.

Just, because this is the only place where we touch OPcache settings, can you try to comment all opcache.* lines inside /etc/php/7.0/mods-available/opcache.ini (not the one that loads the module itself, just the settings. Comment them with ; .
Then:

and see if the error still shows up (with default settings then).

MichaIng commented Nov 27, 2018 •

https://forums.zend.com/viewtopic.php?t=113253
memory_limit , must this in case be as large as opcache.memory_consumption + opcache.interned_strings_buffer , so being an overall limit? But actually no chance to hit that with Nextcloud 🤔 .

@Twilight0
Okay some more to check, going through the memory limits and consumptions:

And you can also check the actual PHP memory consumption of OPcache and APCu:

Ah just saw you sent a bug report. I will also go through it there.

Fourdee commented Nov 30, 2018

Issue appears limited to this device + pre-image. Could be a PREP issue (unlikely if everything else is working fine)

Which pre-image/image did you use for the OPi Zero?

Twilight0 commented Nov 30, 2018 •

Armbian’s one. Stable PREP script & stable Dietpi release. Will report back when I have time to test things out.

MichaIng commented Nov 30, 2018

@Twilight0
Could you please paste the output of above mentioned commands? If all this is as expected, perhaps there is a sysctl.conf/sysctl.d/*.conf entry that somehow limits memory allocation. Not sure what’s possible there.
And could you send a bug report?

But perhaps it’s easiest of @Fourdee can try to replicate, if you have a OPi Zero there? Even it is an issue with a non-officially supported device, perhaps there is some setting outside of PHP that causes this issue that we then need to check/adjust on PHP install.

Twilight0 commented Nov 30, 2018 •

grep ‘memory_limit’ /etc/php/7.0/*/*.ini /etc/php/7.0/*/*/*.ini

/etc/php/7.0/cli/php.ini:memory_limit = -1
/etc/php/7.0/fpm/php.ini:memory_limit = 128M
/etc/php/7.0/phpdbg/php.ini:memory_limit = 128M

grep ‘opcache.memory_consumption’ /etc/php/7.0/*/*.ini /etc/php/7.2/*/*/*.ini

/etc/php/7.0/cli/php.ini:;opcache.memory_consumption=64
/etc/php/7.0/fpm/php.ini:;opcache.memory_consumption=64
/etc/php/7.0/mods-available/opcache.ini:opcache.memory_consumption=10
/etc/php/7.0/phpdbg/php.ini:;opcache.memory_consumption=64
grep: /etc/php/7.2///*.ini: No such file or directory

grep ‘apc.shm_size’ /etc/php/7.0/*/*.ini /etc/php/7.2/*/*/*.ini

/etc/php/7.0/mods-available/apcu.ini:apc.shm_size=10M
grep: /etc/php/7.2///*.ini: No such file or directory

Filesystem 1K-blocks Used Available Use% Mounted on
udev 87112 0 87112 0% /dev
tmpfs 24580 4592 19988 19% /run
/dev/mmcblk0p1 14905760 3211112 11517444 22% /
tmpfs 122888 0 122888 0% /dev/shm
tmpfs 5120 0 5120 0% /run/lock
tmpfs 122888 0 122888 0% /sys/fs/cgroup
/dev/sdb1 3658611 26655 3432225 1% /mnt/flash
/dev/sda1 976760532 749137600 227622932 77% /mnt/toshiba
tmpfs 1047552 0 1047552 0% /tmp
tmpfs 10240 1476 8764 15% /DietPi
tmpfs 51200 120 51080 1% /var/log

total used free shared buff/cache available
Mem: 240 65 58 13 116 153
Swap: 1807 0 1807

However these are after clean install plus a few things without Nextcloud marked, because in case I try installing Nextcloud, it will ruin the system with ncc maintenance error messages etc.

MichaIng commented Feb 4, 2019

Details:

• Date | Mon 4 Feb 04:37:16 CET 2019
• Bug report | N/A
• DietPi version | v6.20.6 (Fourdee/master)
• Img creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi 3 Model A+ (armv7l) (index=3)
• Kernel version |

Letsencrypt supports Free Noip.com Dynamic DNS #1159 SMP Sun Nov 4 17:50:20 GMT 2018

Steps to reproduce:

1. Install Nextcloud through dietpi-software .

Expected behaviour:

Actual behaviour:

• Installation interrupts with error.

Extra details:

• Selected Nextcloud to be installed from dietpi-software . DietPi was freshly set up, nothing was on storage, yet.

Additional logs:

Log file contents:
Mon Feb 4 04:35:56 2019 (22158): Fatal Error Zend OPcache cannot allocate buffer for interned strings

No OPi specific issue then. @Akito13 could you please as well paste the outputs as mentioned above: #2293 (comment)

jbsky commented Jul 18, 2019

Nothing to do with your application that I don’t know, however, I’m confronted with this bug.

Indeed, I have a firewall in VM Pfsense that runs with 256Mb, if I pass it to 512MB of RAM, I have the error mentioned.

MichaIng commented Jul 19, 2019

@jbsky
Thanks for sharing.

Possibly this error can occur on low RAM systems (256M) if the PHP/OPcache memory limits exceed available (or free?) RAM.

Strange is that the error states the interned strings buffer allocation to fail, since this one is very small (4M default, 8M as we set on Nextcloud install due to admin panel warnings/recommendation).
What should fail in the first place is the overall OPcache memory limit which is 128M by default since PHP7.0.

And you say if you set overall PHP memory limit from 512M (default on Debian) to 256M, it does not occur? Even more strange.

I will play around with a 256M memory VM as well and try to replicate.

mtruitt commented Aug 12, 2019

I ran into this same issue @MichaIng and you are correct it will throw this error on low RAM systems that use more than the actually amount available.

I have an application that I cranked the instance size up and adjusted opcache.memory_consumption. Friday I turned it back down as there is no traffic over the weekend and came into that error.

I actually didn’t adjust the PHP memory limit for itself. Just the opcache memory consumption so that may help some in tracking it down.

MichaIng commented Aug 12, 2019

Okay I reopen this to not forget the testing on VM. We’ll see if it depends on total memory, free memory and if total PHP memory limit has any effect.

MichaIng commented Oct 1, 2019

Hmm just got on fresh 1 GiB RAM Buster VirtualBox machine:

The PHP memory limit is below the recommended value of 512MB.

The following then solves the warning:

Since we do not touch this value, it’s Debian Buster package default:

Strange that I never faced this before. New on Nextcloud side? Would be a real problem since low RAM devices (RPi1 with 256M) are perfectly able to run a single user or family Nextcloud instance and should never set memory_limit > 128M of course.

MichaIng commented Mar 11, 2020 •

Okay, I ran some tests and was able to produce the following error on PHP-FPM start/restart:

Basically this appears in two cases:

1. The virtual memory of any PHP child process exceeds the available system memory, including swap files, minus a few megabytes.

• The assigned opcache.memory_consumption increases the virtual memory usage 1-to-1.
• The assigned opcache.interned_strings_buffer has no effect on virtual memory usage, it seems to be included in the overall OPcache memory consumption.
• memory_limit as well has no influence, also I think the border at which those are active, are different. opcache.memory_consumption limits the overall OPcache consumption, as it’s virtual/shared memory, across all PHP-FPM child processes, I guess, while memory_limit is a per-script limit.

1. opcache.interned_strings_buffer is equal or larger than opcache.memory_consumption .

• This fits the above assumption that opcache.interned_strings_buffer is included in opcache.memory_consumption .
• However default values and those applied by us on Nextcloud installs provide a every large difference between the two sizes (default: 128 vs 4, DietPi + Nextcloud: 512 vs 8), hence this cannot be a reason. EDIT: Confused with memory_limit

If I reduce system memory or raise memory usage by other processes, while keeping the above rules, I run into usual OOM killer.

Источник