После обновления 4.1.19.4 - в файле constants.php появилась такая вот запись

define( 'READ_WRITE_SEPARATION', false );

что это за хрень..и на что она влияет? кто замечал...у кого тоже такая строка появилась?

 

Цитата

 

В некоторых инструкциях мы можете встретить отсылку к файлу "constants.php". Файл constants.php это специальный файл, который вы можете по желанию создать в корневой директории вашего IPS Community Suite. Файл может включать в себя специальные команды и конфигурационные параметры, влияющие на нормальное поведение вашего сайта на IPS 4.

Вы можете создать файл в корневой директории вашего сайта, где расположены index.php и init.php, назвав его constants.php. В начале файла должно содержаться:

<?php

Далее могут содержаться любые специальные команды, указанные в наших инструкциях или в админцентре. Многие функции доступны и включают в себя элементы управления кэшированием сайта, функции отладки, а также специальные переопределения, основанные на вашей серверной среде.

Большинство пользователей IPS 4 не должны беспокоиться о файле constants.php, пока не возникнут особые обстоятельства, вынуждающие использовать переопределения.

 

 

да. причины беспокойства есть. изменилась скорость работы на двух разных серверах!

на BSD работает изумительно, пархает еп та, на Linus Ubuntu Server - просто лежит намертво, при посещаемости несколько тысяч человек.

поэтому и спрашиваю...что хрень эта делает?

Можно же попробовать удалить

У меня такой же файл, причем я его собственноручно запихнул на сайт после подключения Memcache - именно при включении кэширования файл создается а требуется в корне. Здесь два варианта, либо сервис кэширования, подключенный через файл (админку IPS) дохлый, либо он просто недоступен на каком-то из серверов. Ну и всё такое. 

1 час назад, sergey81 сказал:

define( 'READ_WRITE_SEPARATION', false );

Конкретно эта опция используется в кластерной конфигурации, когда все запросы на чтение распределяются на реплицируемые узлы.

извиняюсь я не в тему , а какой линукс лудше идёт под ips 4.x ?

Только что, snower сказал:

извиняюсь я не в тему , а какой линукс лудше идёт под ips 4.x ?

а зачем мусорить в этой теме? тяжело свою создать? 

Линукс - это ядро. А дистрибутив на ядре линукса - ну какой Вы освоили, тот и лучший. Я Дебиан использую.

1 час назад, sergey81 сказал:

да. причины беспокойства есть. изменилась скорость работы на двух разных серверах!

на BSD работает изумительно, пархает еп та, на Linus Ubuntu Server - просто лежит намертво, при посещаемости несколько тысяч человек.

поэтому и спрашиваю...что хрень эта делает?

 

1 минуту назад, WOLF сказал:

а зачем мусорить в этой теме? тяжело свою создать? 

мусор ?  ну извините что помешал , не буду беспокойть ....

2 минуты назад, snower сказал:

мусор ?  ну извините что помешал , не буду беспокойть ....

удачи

4 минуты назад, snower сказал:

извиняюсь я не в тему , а какой линукс лудше идёт под ips 4.x ?

на практике рейтинг примерно следующий:

1- идеален bsd сервер с отдельным sql сервером (т.е. файловик по fiber channel с схд на которой sql)

2- пойдет в большой нагрузке сервер debian (серверная семерка), опять же с разнесенным файловиком и sql

3- пойдет на 4+ конфигурация на ssd дисках с debian 7 server

3- если всех интересует ubuntu, то только при минимальной конфигурации системы (т.е. nginx при отключенных всех остальных опциях) причем это крайний вариант использования, т.к. даже при хорошем железе...ubuntu почему то тупит. Вроде должно все быстро откликаться...но в запросах паузы. А так по нагрузке конечно с хорошим железом и слона потянет.

 

примерно по посещаемости: при 100 000 - 200 000 тыс постов платформы, требуется минимум 2 ядра и 1-2 Гб озу с SSD на 10-20 Гб. В такой конфиге выдержит 10-15-18 тыс посетителей в сутки. В час вы можете посчитать сами. Если одновременно...то будут лаги небольшие. Но там все от скина зависит, от кол-ва рекламы. Если вообще голый но забитый постами от разработчика, при правильной настройке всего от php и sql до ips 4 - то в целом 20 тыс посетителей на любом из существующих в стране VDS на debian тянет на ура.

 

Основная проблема это нагрузка при большой конфигурации скина (внешнего вида). Так например боковые блоки на всех типах страниц, по 15-20 записей на них, плюс похожие записи, и прочие виджеты если включить...с рекламой...то загрузка страниц от 3.5 до 17 секунд наблюдается.

Идеальный показатель загрузки страницы до 2 сек. Т.е. 1.3....1.7 секунды. Так может фурычить как паравоз легко

28 минут назад, UraSuper сказал:

Конкретно эта опция используется в кластерной конфигурации, когда все запросы на чтение распределяются на реплицируемые узлы.

ну да...когда мастер и слейв работают распределнно для sql это совмещение записи и чтения базы. кстати с 18 и 19 версии разработчик активно тестирует эту фичу.

если вернуться к теме...то просто удивило, из 10 обновлений, на одном почему-то вылезло в const.php именно эта запись. возможно дистрибутив такой умный что сам определил что там что то с сервером не так и прописал при обновлении. на остальных площадках вообще все чистенько и аккуратненько...только путь прописан до datastore и все.

Все тема закрыта. строку значит удаляем.!

http://loaddy.com/

как вариант теста.

или https://tools.pingdom.com/

А что додуматься нельзя зайти в раздел, где генерируется данный файл и увидеть новый пункт, который отвечает за эту директиву?

5 минут назад, seobot сказал:

 

А что додуматься нельзя зайти в раздел, где генерируется данный файл и увидеть новый пункт, который отвечает за эту директиву?

 

Этот пункт не отвечает за ту директиву...  Включение кеширования шаблонов на диск, вообще никак не управляется из constant.php

итак...после тестов и убийственных манипуляций с живым форумом, выяснилось влияние этой строки.

если в файл constants.php прописать строку....define( 'READ_WRITE_SEPARATION', false );

то вы получаете в результате работы колоссальные нагрузки на CPU сервера в 6-8 раз минимум, приводящие в итоге видимо к распаралеливанию запросов чтения и записи sql.

Т.е. этой записи не должно быть в природе. Не знаю, как она после обновления появилась...руки бы отбивал бы тем кто это сделал

всем спасибо кто откликнулся.

Ничего подобного при обновлении не добавляется!

Странно, убрал, вернул назад на двух форумах - никакой разницы нет вообще. По htop нет различий.

И на "боевом" и на тестовом на 4.2

@sergey81 ясно , я тоже подрозумивал что для ips идеалнее отдельные сервера mysql и файловые для уравновешения нагрузки и большой скорости , спасибо вам за инфу !

В 07.06.2017 в 22:13, Sipsb сказал:

Ничего подобного при обновлении не добавляется!

эта функция, у нас в офисе, прописалась лишь на 1 из 10 форумах. И это была созданная автоматически запись. Во-первых.

Во-вторых, как история показала, этот единственный и был самый древний и старый форум, но обновленный до 4.19 версии. Поэтому костыли могут тянутся из-его детства.

В-третьих ... еще многое от VDS или вашего сервера и его настроек зависить. Так IPS 4 считаю очень продуманной и самонастраивающейся системой. Т.е. возможно при обновлении она сама считывает текущие конфиги сервера и сама там что-либо прописывает в constant.php. Поэтому судить пока некого и нечего. Просто мы увидили в работе такой глюк и сообщили.

Последние наши исследования в этом вопросе указывают на то, что эта запись появиться может в случае если некорректно указан домен системы. Так например при часттом переезде с домена на домен, в старых версиях IPS родной путь или каталог указывался в явном виде в базе IPS (например www.abc.ru так и прописывался в sql, и при переносе на домен www.aaaabc.com, старые пути не всегда были само заменяемы. По крайне мере в старых старых версиях четверки. И поэтому когда в sql после нескольких переездов остаются несколько доменов ... то система возможно и понимает и расценивает их как распределенную структуру SQL серверов с Master и Slave серверами. Якобы www.abc.ru домен в базе есть Master сервер, а домен www.aaaabc.com Slave sql сервер.)

Именно поэтому в самой последней версии обновления разработчик заменил базовый URL на строку формата <base_url>, в котором нет жестко прописанного www.abc.ru домена, а есть просто <base_url> и название домена форума в конфигурационной настройке. Тем самым и убрав эту путаницу при обновлениях или переездах форума с домена на домен.

Поэтому других объяснений мы пока не обнаружили. Писать разработчику не писали, т.к. это целый геммор. Мы все исправили в ручную, т.е. обнаруженные старые домены мы просто в ручную в дампе  sql заменили и все ... теперь ждем нового обновления, что бы увидеть появится ли снова строка define( 'READ_WRITE_SEPARATION', false ); в  файле constants.php или нет.

 

Всем кто читает эту муть...привет)

кстати кто озадачивался редактированием больших файлов SQL можно до 500 Мб легко использовать стандартное unix приложение Geany (обычный блокнот многофункциональный) Открывает до 1 гига легко, зависит от мощности вашего пк и объема ОЗУ. Если у вас дрова, тогда лучше искать замену командой 

grep 'строка_текста_для_замены' -P -R -I -l  * | xargs sed -i 's/строка_текста_для_замены/новая_строка_текста_которой_заменяете/g'

Командой можете и 100 гб текст заменить и исправить. или например в 1000 файлах в одном каталоге заменить текстовую строку на вашу новую 

Парситm большие файлы эффективнее через awk

4 минуты назад, UraSuper сказал:

Парситm большие файлы эффективнее через awk

awk может тупо повесить ваш комп. если 10 гигов будет ваш sql дамп, то awk работает методом перебора построчно. Т.е. ищет сравнения с 1ой строкой, потом снова смотрит 1ую, если нет подходящего...переходит к 2ой строке...если вторая содержит нужный поисковый запрос ... меняет его и все начинается заново. Т.е. там рекурсивный перебор.

Grep более эффективен!

просто сами попробуйте найти и заменить текстовую строку в 10 Гигабайтах awk а потом попробуйте grep и скажите...какой оказался более быстрый и эффективный способ, не подвисая компьютер

Именно для разбора больших файлов awk лучше и быстрее, хотя на вкус и цвет, фломастеров нет

11 минут назад, UraSuper сказал:

Именно для разбора больших файлов awk лучше и быстрее, хотя на вкус и цвет, фломастеров нет

вот именно что мы тестировали для большого размера SQL лучше grep. А awk кладет компьютер...т.к. при рекурсивном цикле поиска и замены строки, он подтягивает все в ОЗУ...и если памяти у вас не 16Гб на компьютере...то ваш awk зависнет)))

вы вообще понимаете о чем пишите? или так...просто слышали где-то когда-то про awk и всё)

Я линуксоид со стажем.

Ну для конкретно Вашей конфигурации может и лучше греп оказался, линукс вообще система хорошая, надежная. но своеобразная

23 минуты назад, UraSuper сказал:

Я линуксоид со стажем.

Ну для конкретно Вашей конфигурации может и лучше греп оказался, линукс вообще система хорошая, надежная. но своеобразная

а вы специалист в какой ветке unix ядра?