Форум

[QUOTE]Maharadg написал:
и что ВЫ там оставили в действии ?[/QUOTE]
На время вообще отключил ежедневный бэкап конфигурации, закоммитить и вручную можно.

Есть ответ про забивание свопа - проблема была в скрипте крона /etc/cron.daily/etckeeper, каждый раз при срабатывании сжирал огромный кусок памяти, забивая swap, и спустя несколько дней process killer в пиках уже решал проблему убивая MySQL...
BitrixWM в штатной конфигурации, памяти 3Гб, ограничения ресурсов были выставлены ansible, их не трогал...

Может, пригодится кому.

Можно просто все существующие значения свойств заказа в шаблон вытаскивать, хоть GetList:
[CODE]<?php

$db_vals = CSaleOrderPropsValue::GetList(array("ID" => "ASC"),array("ORDER_ID" => $orderID, '!UTIL' => 'Y', '!VALUE' => ''));
while($arVals = $db_vals->Fetch()){
  //Хотя вот здесь может быть и проверка на символьный код
  $arFields[$arVals['CODE']] = $arVals['VALUE'];
}

?>
[/CODE]
Или на D7
[CODE]<?php

$obProps = Bitrix\Sale\Internals\OrderPropsValueTable::getList(array('filter' => array('ORDER_ID' => $orderID,'!VALUE'=> '')));
while($prop = $obProps->Fetch()){
  //Хотя вот здесь может быть и проверка на символьный код
  $arFields[$prop['CODE']] = $prop['VALUE'];
}

?>
[/CODE]

del

Можно, если подписаться на событие OnSaleComponentOrderOneStepPaySystem , и там просто unset($arResult["PAY_SYSTEM"][<ваша>]); по проверке условий.

[QUOTE]Maharadg написал:
[QUOTE] dimidn написал:
Тоже самое, проверил на двух машинах. Подскажите есть вариант решения[/QUOTE]
В постах "Игорь Горгуль" решение было - а данная ошибка тянется уже около полутора лет.[/QUOTE]
Спасибо, нашёл, про что пишете.
Он просто обрезал MaxRequestPerChild на сколько я понял. Попробуем конечно. но анализ свопа показывает что там только половина занята httpd, вторая половина - от MySQL.

И у нас. При чём при использовании cron - просто молча в облако не заливается и всё. Хотя локальная копия создаётся.
А при выборе "через облачный сервис "1С-Битрикс"" -

ERROR_10 Secret key is incorrect


p.s.: при попытке прямого запуска
[bitrix@]$ /usr/bin/php /home/bitrix/www/bitrix/modules/main/tools/backup.php
0.09 sec        BitrixCloud is not available
0.09 sec        Backup started to file:

[QUOTE]Just Ahmed написал:
На небольших ИМ эти бесполезные лишние запросы не критичны, а при высокой посещаемости, дают существенную нагрузку + выедают лимиты.[/QUOTE]
Есть ещё интересный вариант отключения ненужного насовсем (неявно из курса).
Если в папку /bitrix/php_interface/include/sale_delivery/ положить пустой файл с именем имеющейся, но ненужной службы доставки (в точности как в /bitrix/modules/sale/delivery/ ), то запросов не будет вообще:
т.е. пустые файлы
/bitrix/php_interface/include/sale_delivery/delivery_pecom.php
/bitrix/php_interface/include/sale_delivery/delivery_cpcr.php

[QUOTE]diyan написал:
А у всех на 7.2.2 такая штука с оперативой:     Скрытый текст        [URL=http://take.ms/0Tj2T]http://take.ms/0Tj2T[/URL] [/QUOTE]
У нас хуже: постоянно забивается своп. уже и до 1500Мб его увеличил. и число процессов апача уменьшил, и всё равно ...

Метод [URL=http://bxapi.ru/src/?module_id=sale&name=CSaleOrderUserProps::Add]CSaleOrderUserProps::Add[/URL]
вообще не подразумевает никаких событий, как и [URL=http://bxapi.ru/src/?module_id=sale&name=CSaleOrderUserProps::DoSaveUserProfile]CSaleOrderUserProps::DoSaveUserProfile[/URL] но можно привязаться к событию OnSaleOrderBeforeSaved ,
и проверять на $order->isNew() и нечто вроде[CODE]$profileIsNew = false;
foreach ($arResult['ORDER_PROP']['USER_PROFILES'] as $profile)
{
if ($profile['CHECKED'] == 'Y')
{
$profileIsOld = true;
break;
}
}
[/CODE]как вариант.

Но вытаскивать сам профайл потом всё равно только поиском по совпадению имени плательщика, уже после создания заказа. Других адекватных способов в голову не приходит.