<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
А можно узнать размеры базы и параметры оборудования?
А из КИПа кроме ЦУПа чем-нибудь ещё пользовались? ЦКК, например, нагрузочное тестирование?
У меня есть несколько вопросов по архитектуре описываемой высоконагруженной системы:
1. Какое разграничение прав доступа используется? Используется ли RLS? Какое количество в среднем различных ограничений видов доступа на одного пользователя?
2. Какая структура кластеров 1С? Используется ли масштабирование средствами 1С? Используется ли резервирование средствами 1С, каков параметр отказоустойчивости?
3. Используется ли виртуализация?
4. Конфигурация на обычных формах?
5. Какова средняя сложность запросов отчетов? Сколько таблиц участвуют в соединениях, есть ли виртуальные?
P.S. Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))
700 тысяч проведений в сутки??? Мы не знаем что со своими 100 пользователями в УПП делать а тут такое =0
(3) Red_Devil, выкиньте УПП, заведите отдел разработки в 40+ человек, запилите самописку, пригласите ЦКТП.
(1) baton_pk,
На текущий момент файл данных >4Тб
По железу можно посмотреть в проекте ЦКТП не один-в-один, но очень близко.
Из КИП еще пользовались стандартным нагрузочным тестом, под определенные задачи он подходит. ЦКК не использовали, присматриваемся.
(2) ivanov660, Присоединяюсь к вопросам.
можно узнать подробности при переводе на 8.2? с какими трудностями столкнулись, что не учли помимо тестирования?
в чем он заключался, просто в конвертации? отказывались ли от совместимости?
в рамках проекта цктп какой франч участвовал ?
(4) baton_pk, аа у них самописка, тогда конечно можно написать документ с 1 регистром =) Жаль в типовых такого не добьешься.
(8) Скорее всего в этой самописке регистров больше чем в типовой УПП.
(2) ivanov660,
1. RLS не используется. Разграничиваем двумя этапами — роли (предварительное разграничение) и регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.
2. В кластере один центральный сервер и 3 дополнительных. Из «особенностей» только то, что у центрального сервера нет rphost’ов (APDEX у пользователей, работающих на процессах центрального сервера, стабильно хуже чем на других серверах). Резервирование кластера не используем, рассматривали возможность — пугает большое количество негативных отзывов, поэтому надо делать тестирование на 3500+ юзеров. Сейчас отказоустойчивость обеспечивается количеством доп серверов (если один выходит из строя — кластер будет способен это пережить) и отсутствием процессов на центральном сервере.
3. Виртуализация только на терминальных машинах. Добавляли в кластер виртуальный сервер 1С, идентичный по железу, APDEX на нем был на 1 — 2% ниже.
4. Формы обычные, клиенты толстые)
5. Сложные запросы. Архитектура изначально строилась по принципам «нет лишним таблицам» и «зачем нам регистр, если все есть в документе», поэтому все не просто.
3000 пользователей у нас работали еще на 8.1 и все было отлично. Перефразируя классика, «роль управляемых форм в производительности сильно преувеличена» 😉
(7) kolya_tlt, Переход на 8.2.13, тот который делали своими силами, провалился из-за поведения кластера 1С — он отказывался балансировать сеансы. Все пользователи оказались на одном сервере — самом мощном по железу. Плюс кластер постоянно «тасовал» сеансы между процессами. Конфигурацию готовили без совместимости, все программные «нюансы» выловили при тестировании логики. Вот список замечаний, который мы в то время для себя составляли:
-Работа с NULL в запросах при использовании конструкций вида ЕСТЬNULL(«(«+Таблица.Поле+»)») // старый комент, возможно исправлено в свежей версии
-Проверить наличие везде проверки на ОбменДанным.Загрузка // для репликации
-Заменить вызова ОткрытьФормуМодально()
-Убрать третий параметр из вызовов ПравоДоступа()
-В процедуру обработчик события «ОбработкаЗаполнения» передается структура, в которой может и не быть поля Ссылка.
-Исправить формат булево по умолчанию на Истина и Ложь.
-Не работает формат даты с использованием YYYY
-Функция ТипЗнч() — не возвращает «…Ссылка…», «Документ..» и т.п., соответственно не работает код вида Найти(ТипЗнч(СсылочноеЗначение), «Справочник»)
-При не использовании Наименования или Кода справочника необходимо отключить его проверку — открыть СтандартныеРеквизиты на закладке объекта Данные и в свойствах нужного
реквизиты указать Проверка — Не использовать.
-Ошибка при выполнении кода вида: ТабДок.Вывести(ТабДокКопия.Область());
-Не работают запросы с условием вида &Контрагент В (Таблица.Получатель, Таблица.Отправитель, Таблица.Объект) если какое то из полей Таблица.Получатель, Таблица.Отправитель, Таблица.Объект — составного типа // всегда возвращается ЛОЖЬ
-Не работают запросы с условием вида ГДЕ Документ.ТабличнаяЧасть.Ссылка ЕСТЬ НЕ NULL // всегда возвращается ИСТИНА
-Для протокола POP3 не корректно работает метод ИнтернетПочта.ПолучитьЗаголовки(); // все заголовки с одинаковым идентификатором сообщения
Показать
Привлечение ЦКТП изначально и обосновывалось необходимостью повысить стабильность работы платформы. Плюс мы решили вторую задачу — спрогнозировать поведение системы при двукратном увеличении количества пользователей (и производимой ими работы есессно).
Про франч — приводил ссылку на проект. Богачев Виктор (участвовавший эксперт) так же был на конференции и подробно рассказывал про это тестирование.
А вот мне стало интересно, ну что же это за контора то такая с такой базой? Энергетики или нефтяники что ли?
(3) Red_Devil, ну так УПП ж. Ужасающе неоптимизированный продукт по производительности. Даже 5 пользователе могут рождать deadlock`и.
Автору огромное спасибо! Очень востребованная тема. Столько боли прожито с производительностью. Почему-то в нашей стране считается, что оптимизация sql это вопрос программистов 1С, хотя 101% из них не обладают не то, что достаточными, но даже начальными знаниями в этом вопросе.
Отдельное спасибо за скульные запросы. Будем пробовать.
(12) DoctorRoza, «Деловые линии» — транспортная компания.
(15) Bronislav, раскрыл интригу)) приятно было быть нефтяником 😉
(6)
Я работаю с базами на порядок меньше (сотни гигов), но уже там возникают проблемы, как то:
1) резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются
2) обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.
3) данные: вычистить мусор, пересчитать итоги (на базе в 600 гигов это занимало 10 часов на MSSQL и 12 на Постгресе), конфу поменять, индексы добавить
как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?
PS. кстати, не пробовали dt-шку выгрузить ? 😀
(11) 1. в итоге какая версия платформы вела себя достаточно стабильно для текущей работы?
2. чем и зачем заменяли ОткрытьФормуМодально?
3. что подразумевается под «Исправить формат булево по умолчанию»?
(0) Со всем уважением к автору и к его докладу!
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. 🙂
База самописная — это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно — из них половина это исправления текущих косяков разрабов?
Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()….в итоге перешли на ПостроительОтчетов….дауншифтинг…
Абзац по сути ни о чем. Если бы вы показали, какой кривой запрос был написан изначально, а какой стал в итоге, то это плюс тому кто в этом разобрался, и минус всей команде сразу, что допустили кривоту. Я за свою практику навидался так диких отчетов (запросов), что могу представить какие у вас были…
Штат разработчиков 20 человек. Сколько из них сертифицированы? Сколько из них с опытом свыше 3 лет программирования и консультирования? Вы извините , но 20 — ни о чем не говорит. А вот 20 профессионалов своего дела — уже впечатляет. 🙂
(0) глава «Разделяй и властвуй» — очень поучительна!
фирма 1с исправляет ошибки платформы исключительно для вас (в рамках договора цктп)? то есть вы остаетесь на том же релизе платформы, только с исправленными ошибками платформы? так что ли? при этом остальные компании исправления этих ошибок или получают с новыми релизами платформы, или не получают вовсе. правильно я вас понял?
(0) ЦУП появился до управляемых форм…. Управляемые формы покамест тормозят и требуют дорогого железа….. неужели такой супер ЦУП не может выявить проблемы управляемых форм?….
какую помощь оказывает цуп? только лишь такую, что начинает контролировать разработку кривых запросов программистов….теперь их можно уволить — есть доказательства их некомпетентности ….
ужас… механизм не то чтобы «не гибкий», а спорный в использовании….
(10) спасибо за подробности! смелый шаг!
(0), (17) 4 Тб — тоже ни о чем!
есть много планов обменов, которые дублируют информацию….
классификатор адресов сколько съедает места?
классификатор банков? Деловые линии работают по всей России и м.б. за рубежом…
свертку давно делали?…
половину инфы можно удалить из рабочей базы — номенклатура которая сто лет не используется, контрагентов, которые давно не существуют, документы прошлых закрытых периодов например за 2000 год…. кому они нужны в текущей рабочей менеджерской базе?….
есть архив, если надо оттуда все достанете, есть дублирующая база, из нее можно вытащить любые документы…..
я уверен, что можно обойтись без цупа
ЦФ-шник в студию — уверен, что косяков там достаточно….
(26) Rustig,
мальчик, может тебе ключи от дома дать, где деньги лежат? (с) не_моё
(22) Rustig, Нет, выходит официальный релиз, никаких исключений.
(20) Rustig, Статей и докладов на тему оптимизации запросов очень много. Не было смысла тратить время конференции, тем более сразу за мной на эту тему выступал Андрей Бурмистров.
Про команду — сильная команда, 7 экспертов (4 сертифицировались уже работая у нас). Но берем не за корочки вовсе, это не показатель.
(23) Rustig, Где управляемые формы? И при чем тут ЦУП…
(30) Сергей, я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику — решение точечное — производительность увеличивается… в докладе нет анализа первопричины проблем, есть диагностический инструмент…. пусть мое мнение будет на ветке….
по поводу управляемых форм — это вопрос не к вам… это риторический вопрос ко всем кто работает с цупом и знаком с тормозами управляемых форм…
спасибо за доклад и статью, считаю ее полезным кейсом )) всего доброго
(24) Rustig, прошу аргументировать и предложить вариант
(26) Rustig,
классификатор адресов сколько съедает места?
классификатор банков?
номенклатура которая сто лет не используется, контрагентов, которые давно не существуют
поверьте, это всё такая мелочь 🙂
(17) baton_pk,
Благодаря AlwaysOn и отчетной базе у нас всегда на готове 2 базы — копии. Но и ежедневное бекапирование делается, чуть дольше 3х часов идет.
Регламентные долго идут, за ночь не успевает. Пробовали несколько вариантов их организации, сейчас остановились на еже ночном обновлении статистик а переиндексация и дефрагментация в выходные.
Не скупимся на СХД 😉 Жертвуем реструктуризацией.
Попробую расскажу)
(18) kolya_tlt, Версия платформы — начиная с 8.2.19.83, сейчас обновились на 8.2.19.130
не актуальный комент, у нас в 8.1 была своя такая функция, поэтому пришлось переименовывать
В конфигураторе, Администрирование — Региональные установки, в 8.2 по умолчанию стоит Да и Нет — части пользователей не понравилось. Мы и цветовую схему настраивали максимально близко к 8.1
(26) Rustig, вы поймите, у оптимизации есть 2 пути:
1. отрезать лишние данные так как неоптимальный запрос их обрабатывает. отрезать можно тоже либо отказать от функциональной части, либо убрать старые данные
2. переписать неоптимальный запрос.
Думаю в проекты был выбран второй путь
ps косяки есть в любом цф-нике. вам зачем на них смотреть?
(35) а может быть актуализируете список ? 🙂 по возможности конечно.
1. зачем нужна «Проверить наличие везде проверки на ОбменДанным.Загрузка» ?
2. «Не работает формат даты с использованием YYYY» не работает где? и как вообще такое искали в коде?)
(19) Rustig, (26) Rustig, (31) Rustig,
За тональность извините. 🙂
Спасибо за вопросы. Видел методичку, как по задаваемым вопросам понять настроение человека и что его беспокоит, видимо много багов и косяков вас окружает 😉 но это так, не много не в тему..
Обновления еженедельно — из них половина это исправления текущих косяков разрабов?
ЦФ-шник в студию — уверен, что косяков там достаточно….
Слишком много внимания косякам, конечно есть и ошибки и просчеты, есть экстренные хотелки бизнеса, а ля «должно работать завтра». Не ошибается только тот, кто ничего не делает.
Но что бы половина обновления — исправление ошибок, серьезно? Частота обновления и количество программистов приведено для понимания скорости наращивания функционала. Постоянное развитие базы — это наша специфика.
Управляемые формы не использовались, на 8.2 мы перешли только в прошлом году, т.ч. основная разработка велась на 8.0 и 8.1
Формы списков — обычные, запросы которые вышли в топ — платформенные вызываемые, например, при скроллинге и выводе списка.
Построитель — да, «не красиво», но личное мнение, что для высоко нагруженных систем будущее за статичными формами поиска (интерфейс SAP это подтверждает). И красивые возможности типа таких без контроля по каким колонкам можно искать, по каким можно искать строго на равенство, по каким нельзя сортировать и т.п. — пугают потенциальным воздействием на систему.
Есть конечно. Это и рост самой компании и потребностей в части функционала.
(37) kolya_tlt, список актуальный, выкиньте пункт ОткрытьФормуМодально(), ну а формат булево по умолчанию — дело вкуса))
ОбменДанными.Загрузка нужна для корректной работы обменов. Ну и вообще наличие этой проверки в событиях ПередЗаписью, ПриЗаписи это уже стандарт.
Ни в 8.2 не в 8.3 не работает, попробуйте выполнить Формат(ТекущаяДата(), «ДФ=dd.MM.YYYY»)
Искали просто — глобальным поиском строку YYYY с учетом регистра.
А бух. учет где ведется? Обмен?
(40) molodoi1sneg, Бух учет ведется в типовой, первичка грузится через обмен.
(41)
ооо! а вот тут-то самая вкусняшка начинается!
двусторонний обмен? коллизии? блокировки при обменах? размеры пакетов?
(42) baton_pk, неа, не начинается)) Обмен односторонний + закрытие периода, поэтому блокировок и коллизий нет.
(41) А вот тут интересно, для типовых конфигураций применяли такие-же методики анализа проблем?
(26) Rustig,
классификатор адресов сколько съедает места?
классификатор банков?
Вы точно сталкивались с большими базами?
(6) замечательно. Отличный опыт. Спасибо что поделились. Пожалуй перейму пару идей 🙂
(33) я не уверен, что мелочи.
мы с вами на разных уровнях работаем. это не плохо, это очень хорошо, особенно если я что -то полезное черпаю из ваших знаний.
это все мелочи, пока у вас есть деньги на железо, на штат сисадминов, на серверные субд… мне в своей практике приходится сталкиваться с файловыми базами, у них ограничение на 4 Гб. и тут я начинаю выдумывать всякие финтиплюшки — картинки и пдф-счета, договора выношу в другие базы (число баз для хранения картинок, образов, сертификатов и т.д. неограничено и постоянно растет), свертка-свертка-и еще раз свертка….
сейчас я понимаю, что о некоторых аспектах никто не задумывается, пока есть деньги на железо, на сисадминов, на лицензии серверов, на цуп… если вы скачаете кладр с официального сайта, получите файлы около 320 Мб. если закачаете часть регионов кладра в базу БП 2.0 получите увеличение базы на 1Гб и выше. просто задумайтесь, что для кого-то это уже не мелочи…
я понимаю, что в пон-к вы продолжите заниматься своими текущими задачами с базами 300 Гб, и продолжите строить планы, как их реиндексировать, понимаю, что вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб….
(38) Вы точно уловили мое настроение! +
(45) ответил в (46)
сталкивался с базой 150Гб будучи в команде разработчиков, за производительность не отвечал, вел разработку подсистем.
в дальнейшем во фрилансе работал с клиентами, разрабатывал подсистемы на файл-серверных базах размеров 40-70 Гб. Приходилось консультировать клиентов как ускорить работу 1С — в моих руках не было цупа, только голова, оптимизация запросов, оптимизация бизнес-процессов и архитектуры новых подсистем.
при работе с файловыми базами сталкивался с падением производительности при достижении базы критического порога допустимых размеров. принимал активное участие в ликвидации последствий.
Я не системный администратор, я программист. и смотрю на данный кейс как программист…
(38) Сергей, у вас много точек продаж, по факту они работают с «потоковым» клиентом. Очень напоминает розницу. Не думали представить всю вашу схему работы подразделений как сеть розничных точек продаж — на каждой точке своя небольшая база, вся информация собирается в центральной базе и т.д. и тому подобное?
(0) свяжу ваш кейс со статьей
так сказать на будущее
(46) Rustig,
Не в этом дело. Просто ваш ответ был в контексте 4ТБ, а для 4ТБ что гиг, что двадцать — мелочи.
70 магазинов с файловыми базами 2-4 ГБ, в каждом магазине по две: на складе и в магазине. Падают часто. Так что, да, мне тоже придётся скоро оптимизировать и их работу тоже :).
(49) Rustig,
нафигнафигнафигнафиг! если есть возможность работать напрямую, лучше работать напрямую. разбить одну база на две — это уже довольно эпохальное решение, а разбивать её на десяток — ошибка и тоже довольно-таки эпичная. в статье от Старых, ссылку на которую вы тут привели, описано, что не всегда параллельность даёт нужную отдачу. в случае с базами — это немалые накладные расходы на обмен.
(49) Rustig, первый совет, с которого начинается книга Фаулера о распределенных системах звучит так — «не распределяйте системы! ну а если это по каким-то очень веским причинам невозможно, то для вас следующие 600 страниц текста». примерно так…
(49) Rustig,
Думали, точнее не так, правильнее сказать, что изначально именно так и было 🙂
Повторю фразу, которую сказал на конференции: те, у кого одна большая база думают над её разделение, а те, у кого распределенная система, думают над её слиянием. Потому что не бывает идеальной системы, минусы есть и там и там.
«Распределенка» это как раз из рубрики двусторонних обменов, коллизий и не актуальности данных. Сейчас движение в сторону функционального разделения.
Два извечных вопроса интернета: Как? и Зачем ?
С периодичностью раз в полгода на различных евентах появляется человек с базой в десяток тысяч пользователей.
И что удивительно практически всегда там находится SoftPoint.
И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.
Кроме конечно желания генерального. Обычно он и говорит — хочу одну базу.
На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.
О чем и говорит уважаемый Rustig.
Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30.
(26)
Беру свои слова обратно:
4 Тб — тоже ни о чем!Контекст изменился: 4 Тб это очень много, чтобы продолжать работать в том же духе и развивать систему. Кажется пора принимать серьезные меры по изменению ситуации. Проведу аналогию: для файловой базы критичен порог 4Гб, для файл-серверной пусть будет 4Тб… :))
Прошу поправить
.
автор, как решили проблему долгой реструктуризации ? и удаления доп.индексов после реструктуризации
(55) Rustig, аналогия в данном случае немного за уши притянута: для файловой базы ограничение в 4ГБ на одну внутреннюю таблицу — это ФИЗИЧЕСКОЕ ограничение, а 4ТБ для клиент-серверной — исключительно психологическое. База вполне может себе жить и пухнуть дальше до 40, 400, 4000. и если не заниматься доработками, связанными с реструктуризацией, то у платформы есть все возможности сделать так, чтобы пользователь не замечал разницы между большой базой и маленькой (речь, разумеется, не про типовые конфигурации :-D)
(56) Xershi, исправил, спасибо
Прямыми запросами к MS SQL не баловались? Или близость к 1С не позволяет? Или баловались, но вслух об этом не говорят?
а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?
(57) МихаилМ,
У нас ограничение от бизнеса — полное время обновления не должно превышать 2ч. За 2 часа, на хороших дисках, успевает реструктуризироваться почти любой объект метаданных. Есть и объекты, которые за это время не успевают, их мало и чаще всего это что то из базового бизнес-процесса, который редко меняется.
Если надо больше двух часов — разделяем обновление по объектно, если и это не помогает, то эти изменения откладываются до больших праздников.
(61) Painted,
Задач таких нет. Но раньше, в далекие времена 8.0 и когда веб сервисы плохо работали с большим количеством коннектов, то запросы сайта как раз и делали «прямые» запросы в базу-копию (раз в неделю разворачивали из бэкапа)
(62) vec435,
Причин ровно две:
1. 1С справляется и при всех её недостатках она нам нравится.
2. Стоимость. Менять придется не только платформу, но и саму учетную систему, а это очень дорого и очень долго.
(65) Если не секрет, сколько у вас серверных ключей и сколько клиентских и каких, программных или аппаратных?
(66) genayo, Ключи программные. 4 серверных и 3500 пользовательских.
А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании. RDS?
Насколько стабильны показатели APDEX? Какое отклонение вы считаете заслуживающим реакции?
Спасибо.
(59) видел ответы ,некоторые улыбнули 🙂 но не буду вдаваться в полемику, поберегу время.
Есть еще парочка вопросов:
1. Допустим сейчас вы полностью контролируете базу и всех 40 программистов, но предположим ваш сервер устал или что еще хуже — логический сбой БД.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?
Что в этот момент будут делать 3000 юзеров ?
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?
2. Есть такой закон — N 152-ФЗ. Пока вы работаете с юрлицами все неплохо, но как только в вашей базе появляется физ. лицо вам надо соответствовать.
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.
(69) capitan,
Вопросы выводят в плоскость почему одна большая БД плохо (может показалось?). Абсолютно согласен с тем, что у этой архитектуры есть недостатки. И у распределенной системы они так же есть. Наша практика показала, что с точки зрения бизнес процессов иметь единую базу выгоднее. Этот опыт никому не навязывается, просто показываю, что это реально.
Если мы говорим про физическое разрушение БД, когда в базу принципиально нет возможности даже войти, то время восстановления работоспособности менее минуты — достаточно в свойствах базы 1С изменить базу СУБД на отчетную или базу-реплику (AlwaysOn). Все 3 базы на физически разных СХД и физически разных серверах.
В рамках ЦКТП тест был на 5000 пользователей. Что должно этому мешать?
У вас либо есть защитный механизм, либо его нет. Если защита есть, то ей должно быть по фиг 30 у вас пользователей или 3000.
Вообще всегда интересны различные идеи и концепты, они позволяют «расширять сознание», поэтому если у вас есть какое то видение, как разом «побороть» все вышеописанные проблемы, напишите, любопытно.
(70) Капитан имеет в виду формальные проверки на соответствие (много мата пропущено) фз 152, к жизни не имеющего никакого практического отношения, но позволяющего за.. утомить, в общем — любого оператора персданных.
В подобных целях видел регламентную очистку исполненных и закрытых заказов, дабы не попасть по числу объектов под неудобный класс ИС.
А сам на проверке с уверенным видом расказывал, что «архивов у нас нет, всё отлажено и работает без сбоев, поэтому процедуры удаления ПДн после отзыва согласия на обработку не нужны и отсутствуют». Коллеги сдержались, проверяющие изумились, но отвязались.
(71) Зеленоград, Это я понял, я не понял при чем тут 3000 пользователей. Видимо надо уволить 2970 сотрудников компании, ведь с 30 пользователями все намного легче)
(68) asved.ru,
Пользователи с базой работают терминально.
Показатели достаточно стабильны (исключение — время выполнения регламентных операций), в основном диапазон значений колеблется в нтервале 0,98 — 0,99.
Критичные отклонения — ниже 0,9. При 0,95 уже режим повышенного внимания. Но опять таки это наша специфика из-за большого количества пользователей. Грубо говоря APDEX 0,97 означает, что более 3% пользователей работают вне комфортной скорости. 3% это 90 пользователей, т.е. потенциально это 90 жалоб. Поэтому после внедрения APDEX’а была притирка — сопоставляли объем поступающих жалоб со значением показателя.
(31) Rustig, «я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику — решение точечное — производительность увеличивается…»
Придерживаюсь аналогичного мнения. С ЦУП приходится повозиться чтобы его запустить и постоянно натыкался на глюки ЦУП. Быстрее всего текущую картину можно получить по Монитору активности в MS SQL Server — самые длительные запросы.
(75) «Мои доводы против распределенки:
— двух сторонние обмены и как следствие конфликты изменений;
— увеличение парка серверов и баз данных;
— требуется больше серверных лицензий;
— процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база — с меньшим количеством пользователей, но такая же большая.»
Думаю аналогично.
(76) ZLENKO, Монитор активности пользуется теми же динамическими представлениями (dm_exec_query_stats и dm_exec_requests) только более сложно агрегирует получаемые данные.
Можно посмотреть в хранимку tempdb.dbo.#am_get_querystats_…
Сталкивались с тем, что монитор активности сам создаёт нагрузку, особенно если интервал обновления маленький и он открыт у нескольких человек.
(77) На самом деле, часть из этих проблем решаема, приведу пример как это решено у нас (продуктовая дистрибуция), несколько филиалов:
1.Двух сторонние обмены и как следствие конфликты изменений.
Организован РИБ, в каждом филиале подчиненный узел. Вся НСИ вводится только в центральной базе, различные виды документов могут быть отредактированы либо только в центральной базе, либо только на филиале. Аналогично организован обмен с бухгалтерской программой. Конфликты изменений практически исключены.
2.Процесс обновления более трудоемок за счет увеличения количества баз.
На самом деле, это критично если баз больше 10-15, на меньшем числе увеличение трудоемкости малозначительно, причем, при желании, это все можно еще и автоматизировать.
3.Все равно появляется центральная база — с меньшим количеством пользователей, но такая же большая.
В центральную базу переносится не вся информация из филиалов, а только те данные, которые нужны для построения сводных отчетов по всей компании. В нашем случае, например, только информация о продажах.
4.Увеличение парка серверов и баз данных, требуется больше серверных лицензий — в общем, это не очень большие затраты, если «размазать» их на все время эксплуатации железа.
Очевидно, что этот подход также имеет свои минусы, но вполне себе имеет право на жизнь.
Автор конечно молодец, очень интересный кейс, но по моему личному мнению 3500 пользователей в одной базе — это несколько перебор 🙂 и бездумно брать этот пример и пытаться повторить не стоит…
(79) genayo,
Спасибо за опыт. Все имеет право на жизнь, и у всего есть как минусы так и плюсы.
Если говорить о комфортных 100 пользователях в одной БД, получится 30 баз))
При текущем анализе возможности функционального разделения базы (не территориального, именно функционального) рассматривался вариант минимум из 10 баз.
Регистр с информацией о продажах у нас один из лидеров по размеру. Второй лидер, информация о движении груза, так же будет нужен в центральной БД для построения статистических отчетов. Мы оценивали какой бы мог быть профит и получается, что самые объемные таблицы все равно будут нужны в центральной БД. Как вариант — переписать всё, сделав разную конфигурацию под центр и под филиал. Продумав логику хранения данных можно будет что то сэкономить. Долго и дорого, но возможно.
Главное то, что кластер 1С справляется с этой задачей. У многих есть опасения именно это момента.
(79) genayo, не могу удержаться от off топа)
Бездумно — нет! Но пробовать и повторять — однозначно стоит! Сейчас для этого есть все инструменты и даже поддержка от 1С (ЦКТП). Чем больше будет подобный кейсов, тем лучше.
(81) У меня есть аргументы против такой точки зрения, но тема то конечно не про это, поэтому здесь их высказывать не буду. Позволю себе еще один вопрос вдогонку — вы хотя-бы гипотетически рассматриваете переход на 8.3, или вы считаете, что без новшеств, добавленных в 8.3 можно прожить (себе я тоже кстати этот вопрос задаю, однозначного ответа у меня пока нет…)?
(82) genayo,
Переход на 8.3 рассматривается. Интересны не столько программные «фишки», сколько оптимизация платформы и возможности кластера. Например в платформе изменена работа с временными таблицами (создается кластерный индекс и сам индекс не удаляется после выполнения запроса), наличие физических таблиц срезов. А в кластере привлекает возможность разделения функций по отдельным серверам.
Можно узнать подробнее про процесс разработки?
Какие проблемы возникают с таким большим количеством людей разработчиков в одной базе (у вас ведь одно хранилище или вы пользуетесь другими средствами совместной разработки)?
Как планируется время на выполнение задачи с учетом того, что (мое предположение) часто нужные объекты бывают захвачены другими разработчиками (а ведь еще есть тестирование)?
ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища. Наверное, есть то число, после которого уже увеличение количества разработчиков бессмысленно. Хотелось бы услышать Ваше мнение по этому поводу.
(84) Irwin, не все программисты работают на одну базу. У нас есть и типовые и несколько баз помельче. В этой базе, если не ошибаюсь, порядка 15 разработчиков.
Работаем через хранилище. Снижение конкуренции за объекты достигается разделением кода на логические блоки (функциональные подсистемы) и их выносом в отдельные модули. Для особо популярных объектов разделение вплоть до того, что каждая печатная форма в своем модуле. Плюс есть специализация разработчика, т.е. задачи в рамках одной подсистемы «придут» одному разработчику.
ИМХО, как и при работе пользователей, количество блокировок при разработке зависит от архитектуры конфигурации.
Ничего удивительно ни в размере базы, ни в количестве пользователей нет. Наслышан об успешной оптимизации и рефакторинге кода от непосредственных исполнителей. На сегодняшний день очень много крупных компаний использующих 1С с объемами баз свыше 1 Тр и количеством пользователей от 500 (данные на одну базу). Есть компании в которых используются более 120 независимых баз между которыми осуществляется онлайн обмен. Реструктуризация больших таблиц средствами 1С — процедура долгая и утомительная. Даже при хорошем железе добавление нового реквизита в 1С с простым типом — несколько часов при объеме таблицы свыше 100 Гб и количестве записей от 80 млн. и более, естественно используются другие возможности. Это уже не говоря об удалении такого реквизита :), с проверкой логической и ссылочной целостностью базы. Насколько понимаю — большинство информации находится в документе, регистры задействованы минимально. Это так ? Используете data кластер от SoftPoin ? По заголовку запросов и происходит разделение (перенаправление) на различные сервера СУБД ? Как обошли отчеты в которых требуется создавать промежуточные временные таблицы ?
(86) Slon1c,
Удивительного нет, для того и доклад готовился, дабы меньше удивлялись. Чем больше примеров будет, тем лучше для сообщества.
Реструктуризацию используем только типовую, причин несколько, но основная — добавление колонки в существующую таблицу SQL возможно только с типом «содержит NULL», это может привести к построению плана запроса с избыточными операциями.
И так и нет) Изначально архитектура БД именно так и строилась — все данные в документах (это было сделано осознанно и на то были причины, но это тема отдельного холивара). Но уже несколько лет все новые проекты реализуются с ориентацией на регистры и это, в том числе, значительно увеличило ускорение роста объема данных..
Дата кластер действительно отличная штука, ей бы добавить признание от самой 1С и совместно создать мощный инструмент. На текущий момент оптимизация кода дала такой эффект, что мы можем работать и без отчетной базы и без дата кластера, но обе технологии повышают запас прочности и надежность системы в целом (плюс «горячий» бэкап), поэтому и остаются в строю.
Сергей, подскажите пожалуйста, вы описывали, что у вас достаточно много запросов со стороны сайта к web сервисам 1с. Хотелось бы узнать поподробнее, что используется IIS, Apache?
Какое примерно к-во запросов в минуту/час ? С какими проблемами в этой связке столкнулись?
Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например ?
И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
(88) dablack,
>Хотелось бы узнать поподробнее, что используется IIS, Apache?
Apache.
>Какое примерно к-во запросов в минуту/час ?
Запросов к веб серверам, со слов их админа, порядка 1500/минуту.
>С какими проблемами в этой связке столкнулись?
Работает достаточно надежно. Основное, с чем боролись — настройка таймингов. Суть проблемы (упрощенно) — если запрос выполняется дольше указанного в настройках веб сервера тайм аута, то число коннектов от веб сервера к базе увеличивается. Увеличиваться может до «бесконечности». Для объективно долго выполняющихся сервисов увеличивали тайминг + оптимизация кода и запросов.
(88) dablack,
>Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например ?
Специально никто переписывать обычного клиента не будет — работа ради работы (да простят меня фанаты тонкого клиента и управляемых форм). Остальное будет рассматриваться в рамках запрашиваемой функциональности, если по условию задачи лучшим выходом будет metadata, то в эту сторону и будем смотреть.
>И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Тут все просто. Самописная dll для работы через API CISCO. 1с тут играет роли «выгрузить очередь для обзвона» и «найти клиента по номеру телефона и отобразить данные».
Про это:
Виктор Богачев, Проект по нагрузочному тестированию 1С 8 для 5000 пользователей в одной ИБ
Сергей, Вы пишете:
Вопрос:
Уточните, пожалуйста, какие именно блокировки имелись ввиду? Какие транзакции ожидали освобождения этих блокировок? Конкретно каким образом удалось решить эту проблему? Неужели отказались от использования этого метода? А что использовали взамен?
(87) по поводу новых колонок с реструктуризацией, то достаточно быстрый вариант такой: переименовывается исходная таблица, предварительно создается скрипит CREATE для таблицы. После переименовывания таблица создается, проводится реструктуризация, после чего через INSERT INTO SELECT FROM …в старую уже отреструктуризированную таблицу вставляются записи из переименованной исходной таблицы. В итоге и поля «без нуллов», и данные вставлены куда быстрее, чем штатными механизмами, ибо штатный механизм читает записи, потом проверяет на типы данных, и если тип изменился и теперь не содержится в поле, то он очищает данное поле, после чего уже очищенный вариант пишет в таблицу. Это ну о-о-о-о-о-чень долго…
(101) starik-2005,
не понял профит, именно эта операция самая длительная при типовой реструктуризации.
На сайте уже было одно из решений и мы уже общались на эту тему.
Там, кстати, вы другое решение озвучивали
и оно больше похоже на правду 😉
(102) да, я оба варианта использую. Но в последнее время из-за лени, видимо, чаще именно вариант с копированием применяю. Последний раз данную процедуру буквально на днях применял — у клиента есть регистр с 6кк записей. Достаточно большой. В него добавили ресурс текстовой — строка 10 символов. В итоге система на тестовом стенде реструктуризировалась очень долго — не дождались (думаю, примерно неделя бы ушла). При том вставка заняла всего 3 часа. Но это железки обычные — не ваши.
Есть у меня мнение, что большинство не понимает, как работает реструктуризация. Если бы она просто копировала данные из одной таблицы в другую за раз (ins ert in to tb1 sel ect * fr om tb2), то это было бы просто шикарно и скорость такой реструктуризации многих бы удивила. Но 1С все делает не так. Она читает порцию из таблицы 1, потом обрабатывает ее (проверяет соответствие типов полей с метаданными — как часть механизма), потом эту порцию записывает в таблицу с суффиксом NG. После того, как все объекты обновлены, 1С в транзакции удаляет старые таблицы и переименовывает таблицы NG. Основное время реструктуризации занимает обработка данных платформой, ну и порционность вставки вносят свою лепту, ибо одно дело — один запрос на сервере выполняется, совсем другое — куча запросов + данные, метаемые с сервера SQL на сервер приложений и обратно. Один сетевой трафик чего стоит.
(10) управляемые формы позволяют разгрузить терминальные сервера, а сервер 1с наоборот — загрузить.
1с запретила делать резервирование серверов на 8.2. В 8.3 нет проблем с отказоустойчивостью?
(111)
Так понимаю вопрос касается следующего проекта, уже по переходу на 8.3. Давайте с определением для начала разберемся, а то под отказоустойчивостью можно понимать разные вещи.
Если говорить про резервирование серверов (что и дает полноценную отказоустойчивость), то на 8.3.10 и ранее работает не очень хорошо (в последних релизах оно даже работает, но при включении заметна деградация в скорости работы), поэтому мы пока не используем. Тесты 8.3.11 показывают хорошие результаты, APDEX практически не отличается от режима без резервирования т.ч. надежда есть.
Если же говорить про отказоустойчивость в рамках стабильной работы (отсутствие без причинных вылетов, закрытия сеансов), то тут все хорошо, сейчас работаем на 8.3.10.
(112) Спасибо за ответ. В терминологии могу быть неточен, сорри.
Про деградацию при использовании нескольких центральных серверов в теме. Если центральный один + несколько «вспомогательных» — то вопросов, как я понимаю, в части производительности не возникает?
Меня больше интересовала позиция 1с, раз уж у вас с ними очень тесный контакт )
(113)
тут все нормально, да.
За позицию 1С не скажу)) но в целом видно желание сделать все хорошо и красиво.