Проблема в том, что у нас дополнительно установлен драйвер ODBC, который обеспечивает работу с БД MS SQL. Также нашел PDO sqlsrv, возможно, что он тоже участвует. См. скрин. https://disk.yandex.ru/i/qSeMNS8yB8kljA Опасаюсь, что слетит при обновлении доступ к MS SQL и перестанет работать. Слетит, как думаете?
написал: Проще: Можно через init.php, с помощью функции custom_mail, добавлять в конец подпись https://dev.1c-bitrix.ru/api_help/main/functions/other/bxmail.php Сложнее: Вешать обрабочик на обновление и создание пользователя и создавать (обновлять) ему подпись \Bitrix\Mail\Internals\UserSignatureTable
Нуждаюсь в образце кода. Как работать с \Bitrix\Mail\Internals\UserSignatureTable Цель обновить подпись.
Ахат Баязи написал: Я как-то сталкивался с проблемой увеличения дискового пространства в работающем Б24.Решили так:самый большой объем как правило занимают файлы в папке: uploadмы просто примонтировали на уровне сервера к этой папке внешний большой диск. И все, проблема расширения дискового пространства была решена.
Есть проблема увеличения дискового пространства на виртуальной машине VMBitrix для Битрикс24. Изначально виртуальная машина Битрикс (VMBitrix) устанавливалась с образа, скаченного с оф. сайта https://www.1c-bitrix.ru/download/vmbitrix.php Затем несколько раз производилось успешное увеличение логического диска по инструкции: https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=37&CHAPTER_ID=08883&LESSON_PATH=... За несколько увеличений мы добрались до 1ТБ без замены структуры разметки. Но теперь при попытке увеличить дисковое пространство до 3Тб мы получаем сообщение от системы, что это нельзя сделать без изменения разметки с MBR на GPT. Как я понял, 2 Тб это предел для MBR. Выше 2-х это уже GPT. Инструкции от поддержки как это сделать - нет. Они говорят, что это должен делать наш системный администратор (не против), а они не при чем и подсказок не будет. И это все на работающем Битрикс24, который очень важен и его нельзя сломать.
Сейчас нам надо понять. Как перейти с MBR на GPT для увеличения dev/sda3/ более 2ТБ (до 3-хТб) на работающем Б24, если это вообще возможно. Если невозможно, тогда мы поймем, что 2Тб это предел дискового пространства для Б24, который нельзя преодолеть. Если это предел, то придется планировать, как удержать сайт в этих пределах.
Добрый день! После многих и многих месяцев успешной работы бекапа Б24, на днях он стал выдавать ошибку: "В процессе создания резервной копии произошла ошибка. Подробности в системном журнале". В журнале: "Автоматического резервное копирование, запущенное 26.09.2020, завершилось необрабатываемой ошибкой. Посмотрите логи сервера, чтобы найти причину."
Подскажите, пожалуйста, какие именно логи надо смотреть в данном случае?
Добрый день! Нам тут посоветовали перейти с дефолтного поиска Битрикс на поиск Sphinx. Перешли нормально, но запуск переиндексации завершается ошибкой.
Предположительно, дело в значении max_allowed_packet (в mysql).
Евгений Костюк написал: Значит у ваc или не установлен memcehed или вы не используете стандартную BitrixVM актуальной версии
Выбираю первый вариант)) У нас не установлен memcehed Т.к. у нас точно стандартная BitrixVM. Скачали с оф сайта и поставили по инструкциям от Битрикс. Все по дефолту. Ни шага в сторону.
Но при этом, странно что не установлен memcehed, да? Вы выше писали, что:
Цитата
Евгений Костюк написал: мемкеш по дефолту есть, но он по дефолту не настроен
Евгений Костюк написал: Рейды разные бывают это я к тому что если рейд на ssd sata 2 то это одно а если на hdd sata 2 то это совсем другое! разница в плане случайного чтения может быть в тысячи раз без преувеличений!
У нас hdd sata2 райд10. Но сейчас (по совету) решили докупить один ssd nvme. Наверное, перенесем туда несколько вин-машин. Чтобы разгрузить основной райд. И еще докупим два ssd, соединим в райд1. Наверное, перенесем туда бд битрикс24.
Цитата
Евгений Костюк написал: если нет то нужно указать сервер и порт. Настройки на сервере можно посмотреть поднастроить вот тут: vi /etc/sysconfig/memcached
Добрый день! Недавно нам пришлось проапгрейдить VMBitrix с 7.3.4 до 7.4.11 Сами в этом не разбираемся, пригласили партнера Битрикс. Их спец провел апгрейд на нашем сервере. Но во время работы возник один ньюанс, который хочется обсудить.
Во время процесса апгрейда система выдала предупреждение, что boot диск исчерпал свободное место и процесс не может быть завершен. Не хватало что-то около 100Мб. Спец немного подумал и решил переразбить диски. Он взял 150Мб от своп-диска и отдал boot -диску. После этого перезапустил апгрейд VMBitrix-а и процесс успешно завершился.
Но что меня беспокоит: 1. VMBitrix с 7.3.4 у нас был дефолтный. Странно, что у него boot-диск имел недостаточно места для стандартной операции - апгрейд версии. Сами мы там не копались т.к. не разбираемся. Именно, что все было по дефолту, взято с оф сайта. 2. Текущий размер своп-диска. Спец сказал, что все норм. 3. Но потом приглашенный аудитор нашей системы (проблемы с производительностью) сказал, что у нас неправильный размер своп-диска. Его слова: "Всего 380Мб при 16Гб RAM. Это не правильно." Есть взаимосвязь?
Добрый день! У нас в системе был аудитор (проблемы с производительностью). И одна из проблем, что у нас:
"Есть какие-то доработки, которые хранят свои логи в кэше, что забивает своп и дает сильную просадку дисковой системы. Данные в кэше хранятся, а так быть не должно, поэтому нужен поиск и оптимизация проблемного кода."
Я пытаюсь понять. 1. Что это могут быть за доработки. У нас нет доработок. Стоит несколько модулей из Маркетплейс, но он сказал, что дело не в них т.к. там проверенные модули. 2. Какой кэш он имеет в виду? Начинаю проверять то, что могу посмотреть, кэш вроде не большой по размеру. du -sh /home/bitrix/www/bitrix/cache 81M du -sh /home/bitrix/www/bitrix/managed_cache 19M du -sh /home/bitrix/www/bitrix/stack_cache 16K du -sh /home/bitrix/www/upload/resize_cache 1.3G du -sh /home/bitrix/www/bitrix/wizards 99M
Total number of items stored by this server ever since it started
Number of open connections
Total number of connections opened since the server started running
Number of connection structures allocated by the server
Cumulative number of retrieval requests
Cumulative number of storage requests
Number of keys that have been requested and found present
(NAN%)
Number of items that have been requested and not found
(NAN%)
Total number of bytes read by this server from network
0 Mega Bytes
Total number of bytes sent by this server to network
0 Mega Bytes
Number of bytes this server is allowed to use for storage.
0 Mega Bytes
Number of valid items removed from cache to free memory for new items.
Цитата
Евгений Костюк написал: Как уже писали выше с nvme прироста можно и не заметить возможно это мой случай, а в вашем будет прибавка производительности. Возможно вы используете композит?
У нас райд10 на шести обычных дисках SATA2. Композита нет.
И еще, у нас режим многосайтовости. Это когда одно ядро, два сайта. Первый сайт - это б24, второй - это интернет-магазин. Для второго предположу, что мемкэш полезней.
Алексей написал: На support@ammina.ru напишите.Через недельку у нас выходит конфиг для VDS на базе ISPManager - там поддержка и корппортала и редиса и мемкеша и тп через интерфейс панели самой.Пришлем рассылочку как выпустим (в принципе документация осталась)
Алексей, благодарен Вам. Но с этим мы как обезьяна с очками. Работает и хорошо. Уверен, что нам лучше не трогать, то в чем не разбираемся. Но все равно спасибо!
Спасибо! А в VMBitrix есть мемкэш по умолчанию? Я думаю, что нет. Про redis заинтересовало. Но, видимо, это тюнинг для тех кто хорошо разбирается в системе. Это не про нас. Убрать откровенные косяки - уже хорошо.Кстати, аудитор очень много нашел и проговорил недостатков, что странно, ведь у нас дефолтный VMBitrix, где логично ожидать хорошей сбалансированности.
Добрый день! Хочу рассказать о наших болях при работе с почтой и надеюсь получить совет от опытного человека.
В нашей компании бывает, что электронные письма от клиентов теряются. Бывает, что долго даем ответ. Что-то регистрируется в журнале, что-то нет. Сейчас у нас есть: - общие отделовские (они были изначально, с этих общих ящиков письма "расписывались" руководителем на конечных исполнителей), - персональные менеджеров (их ввели для ускорения работы, но хз как теперь все это контролировать и оценивать).
Вы наверное уже поняли, что в конечном итоге, это разговор про эффективность менеджеров. И о том как измерить их работу в части работы с электронной почтой.Есть понимание, что электронную почту надо как-то регистрировать и измерять. Ломаем голову, как сделать Чтобы письма не терялись. Чтобы по одному письму можно были найти и поднять всю цепочку переписки. Чтобы получить метрики по работе менеджеров с почтой, через которые можно оценить их. Чтобы всегда можно было посмотреть кто из менеджеров быстро отвечает клиенту, а кто нет. Чтобы можно было понять кто сколько подготовил и отправил ТКП, договоров, счетов. Чтобы можно было понять кто из менеджеров сильно загружен, а кто нет. И т.д.
В Б24 есть какая-то своя философия работы с почтой. Но то ли она не ложится на нашу, то ли мы что-то не понимаем. В б24 почта представляет собой какую-то кашу. Почта отправляется/принимается. Она привязывается к каким-то сущностям (лидам, сделкам, контактам, компаниям) по какой-то логике. Из плюсов, что там каждое письмо получает автоматическую регистрацию, это номер и дата_время. Это уже хорошо. Но куча вопросов не закрыты. Эффективно менеджеры с ней работают или нет?
Возможно, что с почтой надо работать по философии тикетов. Когда первое письмо получает номер, а вся переписка цепочкой "нанизываются" на этот номер. Ничего не теряется. В какой-то момент тикет закрывается. Знаю, что есть какое-то ПО для организации тикет-систем, но опыта а в этом нет Но как это взаимоувязать с срм системой Б24, которая у нас уже есть? Я решил спросить об этом у авторитетного для меня человека Антона Долганина. Наверное, многие его знают. Это ответ был примерно: "А чем вас не устраивают открытые линии в Б24? Это современный взгляд на тикеты." Хмм. Что-то в этом есть. Но с другой стороны, при чем тут почта?
Если вам есть что сказать по теме, то буду очень благодарен. Спасибо!
Добрый день! Недавно провели аудит нашего сервера с коробкой Б24 (на VMBitrix 7.4.11). Проблемы с производительностью. И аудитор сказал, что у нас нет мемкэша, и что его надо обязательно настроить. И, что по умолчанию он должен быть. Возникло общее ощущение, что аудитор излишне сгущает краски, чтобы получить заказ. Два вопроса. 1. Странно, что мемкэш должен быть по умолчанию, но у нас его нет. Знаю, что мы все настраивали по умолчанию. Просто взяли VMBitrix и поставили на гипервизор. Внутрь не лазали. Ничего не перенастраивали т.к. не соображаем в линукс-ах. Работает и хорошо. Действительно мемкэш должен быть в VMBitrix по умолчанию? 2. Пообщался со сторонним LAMP-спецом на эту тему, и он сказал, что в Б24 мемкэш не нужен т.к. срм-данные динамичные. Мемкэш имеет смысл например в интернет-магазине или где данные более менее статичны. Мне показалось логично. Это так?