QAru — это мерзотнейшее воровство, потому что у SO свободная лицензия с обязательным указанием источника.
Специально зашел и сделал ctrl-F «stack» на странице с ответом — ни одного попадания. Пускай горят в аду.
Выступлю оппонентом, хотя, конечно, описанная картина выглядит безрадостно.
Просто я вижу, что на sql.ru в разделе по MS SQL модераторы как раз ушли в другую крайность и максимально пошли на поводу у «активного сообщества». В итоге начались вот такие конструктивные обсуждения и разгон «тупых новичков» грязными тряпками. Уже давно ничего спрашивать у этого сообщества не хочется, потому что «нубский» вопрос встретит тонну сарказма с крупицами дельных советов.
Хотя если поиск заносит на какие-то старые темы, там встречаются очень интересные и полезные обсуждения. Все в итоге снова сводится к адекватности модерации.
ну я помню, как в 2008-9 аську (читай: квип) лихорадило, она стабильно пару раз в месяц падала. Бизнес тогда ушел в скайп, а все друзья — в мессенджер вк, который как раз подоспел. Буквально за полгода живой контакт-лист аськи опустел, все разбежались. Оставалось несколько самых упорных, но основное общение уже ушло в другие сети.
Квип пытался добровольно-принудительно перетянуть на свой протокол (на основе джаббера), но не взлетело. Получается, сгубил устаревший протокол и топорные попытки модернизации
Я действительно сейчас работаю как «приглашенный специалист» и вижу разные системы.
Вообще тема такая, что мы можем тут долго препираться: слишком много переменных. Не обговорено изначально число баз, пользователей, серверов — поэтому каждый может «ванговать» удобные для себя параметры окружения и оставаться правым в споре.
По службам — считаю, что это допустимый сценарий, который подходит не к каждой системе.
Про процессоры — да, соглашусь, зависит и от числа пользователей, и от нагрузки. Важно, что в этом обсуждении проговорили, как 1С работает с многопоточкой (никак) — а дальше уже специалист с головой сможет прикинуть свои потребности.
Возвращаясь к статье: тут есть несколько интересных идей, подкрепленных, к тому же, скриптами, т.е. практикой. И это уже интересно и ценно. С чем-то можно поспорить (про кластер или виртуализацию), но в целом, я автора поддерживаю.
А я вот работаю с 1С и поддержу автора. Нормальное руководство, но, скорее не «рельсовый» гайдлайн (только так, иначе никак!) а сборник рецептов, к которым стоит прислушаться, но где-то сделать по-другому.
Кластер у 1С 8.3 есть, и даже active-active. И он хорошо работает в среде Small&Medium Business (не спрашивайте, зачем мелкому бизнесу кластер). Но вот в сложных окружениях он… может и не работать. Сам лично убил несколько месяцев, пытаясь запустить этот кластер: на стенде работает, на проде — нет. Опытным путем выяснили, что он как-то конфликтует с какими-то групповыми политиками — и дальше разбираться не стали, т.к. повлиять на них было нельзя. Но это — исключение, один случай из сотни.
Злого пользователя, формирующего ОСВ за год действительно быстро и просто нейтрализовать, прибив либо его самого, либо его rphost. Но есть вещи, которые живут не только на рабочих процессах — например, сервис нумерации. Да, такие вещи ломаются крайне редко. Но в такой ситуации ребут всей службы действительно может помочь. Возможнсть запускать несколько служб одновременно с разносом по портам — штатная вещь, описанная в том же «Руководстве администратора». Так что никакой крамолы здесь не вижу.
Во времена 8.2 1С рекомендовала использовать вообще один рабочий процесс, с пафосом добавляя, что «Платформа — современное приложение, которое может использовать преимущества многопроцессорных систем». Потом одумались, к счастью. На практике, из того, что видел, пользоавтельский код выполняется в один поток (но разные ядра могут обслуживать разных пользователей одновременно). Поэтому, соглашусь, частота процессора важнее числа ядер.
В целом, надо понимать, что это опыт обслуживания большой инфраструктуры. Поэтому не надо в офис из 10 человек настраивать 3 службы: для розницы, бухгалтерии и зарплаты.
А как набор рецептов для крупной компании — статья, как минимум, интересная. Спасибо за труд и жду продолжения )
На стапелях Jupyter, кстати, уже давно готовится идейное продолжение — JupyterLab (https://blog.jupyter.org/jupyterlab-is-ready-for-users-5a6f039b8906)
Пока отличия по большей части интерфейсные — но с ним уже удобнее работать, чем с обычным Юпитером. Надеюсь, до расширенной и упрощенной визуализации данных «из коробки» руки тоже дойдут.
Ну и бонус для тех, кто уже успел поработать с Jupyter — старые ноутбуки открываются в новой оболочке без необходимости конвертации.
Про SQL\Buffer hit ratio и Page life expectancy поспорю. На современных версиях (фактически, после SQL 2005) коэффициент попадания в кэш почти всегда крутится в районе 95-99% и по нему практически невозможно понять, есть ли какие-то проблемы с кэшем
PLE, наоборот, наглядно показывает, когда место в кэше закончилось — он просто резко обрывается вниз. При этом он может не падать до пресловутых 300 мс, но все равно показывать «пилу» — это означает, что данные постоянно вымываются из кэша. Поэтому рекомендуется смотреть не на абсолютное значение этого показателя, а на его динамику — если он постоянно обрывается, у вас явно не хватает памяти для кэша (buffer pool) и надо либо увеличивать место (т.е. добавлять памяти), либо заниматься тем, что в этот кэш помещается — т.е. оптимизировать запросы так, чтобы они делали меньше избыточных чтений
Подробнее, например, тут
Специально зашел и сделал ctrl-F «stack» на странице с ответом — ни одного попадания. Пускай горят в аду.
Просто я вижу, что на sql.ru в разделе по MS SQL модераторы как раз ушли в другую крайность и максимально пошли на поводу у «активного сообщества». В итоге начались вот такие конструктивные обсуждения и разгон «тупых новичков» грязными тряпками. Уже давно ничего спрашивать у этого сообщества не хочется, потому что «нубский» вопрос встретит тонну сарказма с крупицами дельных советов.
Хотя если поиск заносит на какие-то старые темы, там встречаются очень интересные и полезные обсуждения. Все в итоге снова сводится к адекватности модерации.
Квип пытался добровольно-принудительно перетянуть на свой протокол (на основе джаббера), но не взлетело. Получается, сгубил устаревший протокол и топорные попытки модернизации
Вообще тема такая, что мы можем тут долго препираться: слишком много переменных. Не обговорено изначально число баз, пользователей, серверов — поэтому каждый может «ванговать» удобные для себя параметры окружения и оставаться правым в споре.
По службам — считаю, что это допустимый сценарий, который подходит не к каждой системе.
Про процессоры — да, соглашусь, зависит и от числа пользователей, и от нагрузки. Важно, что в этом обсуждении проговорили, как 1С работает с многопоточкой (никак) — а дальше уже специалист с головой сможет прикинуть свои потребности.
Возвращаясь к статье: тут есть несколько интересных идей, подкрепленных, к тому же, скриптами, т.е. практикой. И это уже интересно и ценно. С чем-то можно поспорить (про кластер или виртуализацию), но в целом, я автора поддерживаю.
Кластер у 1С 8.3 есть, и даже active-active. И он хорошо работает в среде Small&Medium Business (не спрашивайте, зачем мелкому бизнесу кластер). Но вот в сложных окружениях он… может и не работать. Сам лично убил несколько месяцев, пытаясь запустить этот кластер: на стенде работает, на проде — нет. Опытным путем выяснили, что он как-то конфликтует с какими-то групповыми политиками — и дальше разбираться не стали, т.к. повлиять на них было нельзя. Но это — исключение, один случай из сотни.
Злого пользователя, формирующего ОСВ за год действительно быстро и просто нейтрализовать, прибив либо его самого, либо его rphost. Но есть вещи, которые живут не только на рабочих процессах — например, сервис нумерации. Да, такие вещи ломаются крайне редко. Но в такой ситуации ребут всей службы действительно может помочь. Возможнсть запускать несколько служб одновременно с разносом по портам — штатная вещь, описанная в том же «Руководстве администратора». Так что никакой крамолы здесь не вижу.
Во времена 8.2 1С рекомендовала использовать вообще один рабочий процесс, с пафосом добавляя, что «Платформа — современное приложение, которое может использовать преимущества многопроцессорных систем». Потом одумались, к счастью. На практике, из того, что видел, пользоавтельский код выполняется в один поток (но разные ядра могут обслуживать разных пользователей одновременно). Поэтому, соглашусь, частота процессора важнее числа ядер.
В целом, надо понимать, что это опыт обслуживания большой инфраструктуры. Поэтому не надо в офис из 10 человек настраивать 3 службы: для розницы, бухгалтерии и зарплаты.
А как набор рецептов для крупной компании — статья, как минимум, интересная. Спасибо за труд и жду продолжения )
Пока отличия по большей части интерфейсные — но с ним уже удобнее работать, чем с обычным Юпитером. Надеюсь, до расширенной и упрощенной визуализации данных «из коробки» руки тоже дойдут.
Ну и бонус для тех, кто уже успел поработать с Jupyter — старые ноутбуки открываются в новой оболочке без необходимости конвертации.
PLE, наоборот, наглядно показывает, когда место в кэше закончилось — он просто резко обрывается вниз. При этом он может не падать до пресловутых 300 мс, но все равно показывать «пилу» — это означает, что данные постоянно вымываются из кэша. Поэтому рекомендуется смотреть не на абсолютное значение этого показателя, а на его динамику — если он постоянно обрывается, у вас явно не хватает памяти для кэша (buffer pool) и надо либо увеличивать место (т.е. добавлять памяти), либо заниматься тем, что в этот кэш помещается — т.е. оптимизировать запросы так, чтобы они делали меньше избыточных чтений
Подробнее, например, тут