Наличие рабочего экземпляра не отменяет того, что были эти и некоторые другие серии HDD, которые были хуже или сопоставимы с критерием "каждый 10 в первый же год на мусорку", упомянутым в комментарии, на который я ответил. Поэтому я могу сделать только вывод, что у вас есть старый IBM DTLA, а у меня есть старый Seagate Constellation ES :)
А у меня до сих пор лежит мёртвый DTLA для напоминания. И Seagate ES 1ТБ из "той самой" серии (которая была с косячной прошивкой) есть - он сдох, но был восстановлен.
Сам по себе CXPACKET не является проблемой. По факту это практически только индикатор параллельного выполнения: при параллельном плане почти всегда будет часть веток, которые выполнились быстрее, часть - медленно, поэтому SQL Server часть времени проведёт в CXPACKET. Хорошее объяснение есть тут. Бороться с CXPACKET как таковым обычно не нужно. С параллельными планами запросов проблемы другие
В распараллеливание отдаётся план до прохождения всех оптимизаций. Чаще всего это очень неэффективный план. И получаются весы: с одной стороны n ядер, но план с с лишними сканами и неэффективными соединениями, с другой - лишние m миллисекунд на оптимизацию и может быть план с нормальными поисками и соединениями.
Очень низкая граница на распараллеливание. 5 "попугаев" - это "как бы 5 секунд на компьютере 2000 года", причём планировщик запросов редко попадает точно в кост, чем бы он ни был. Для 1С я эмпирически пришёл к тому, что Cost Threshold for Parallelism стоит ставить от 100 до 5000 примерно. Так жирные отчеты пойдут параллелиться, а в проведении SQL будет лучше оптимизировать.
(И это упомянуто в статье) По умолчанию параллелизм съедает все ядра. Ну так MS уже лет 10 (как появились сервера с 64 потоками) советует для многоядерных CPU ставить макс. параллельность 8, если нет особых обстоятельств. Ну от себя могу добавить, что какие-то операции, явно сканирующие большие талицы, можно вручную указывать OPTION MAXDOP по максимуму. В том числе, например, построение статистики и перестроение индексов.
То, что компания и сотрудник не сработались - такое бывает. При этом почти всегда и представители компании и сотрудник считают, что неправа другая сторона, но обычно это всё свидетельство ошибок со стороны менеджмента. Причём ошибок, которые лечатся не размытыми "тщательнее отбирать" и "глубже погружать", а вполне стандартными решениями. Если для вас этот проект ограничен по времени и имеет чёткую цель, то почему у вас сотрудник на обычном бессрочном договоре без рычага в виде существенной премии по итогам? Стандартно это же решается, например, одним из следующих способов:
Срочный договор с большим бонусом в конце (по чёткому критерию)
Бессрочный договор с существенными премиями от результата
Договор ГПХ, если задача "под ключ" - но здесь надо сторить работу не как с сотрудником, а как с подрядчиком
Привлечение сотрудника как аутстафф (да, дороже, но геморрой не ваш)
Решение задачи через аутсорс (но надо быть готовым, что на той стороне не согласятся с тем, что вы не приняли работу - договор, задание и документальное оформление должны быть достаточно чёткими для спора в суде).
Ну и есть еще миллион способов подстелить соломки. Если заранее не побеспокоились, то разойтись на "по соглашению, 2 оклада и отпускные" обычно самое дешёвое и быстрое решение. Внезапные "аттестации" одного сотрудника после угроз и хамства в переписке могут выйти дороже (тут, конечно, лотерея, но я не уверен, что такой "гэмблинг" оправдан).
Все аргументы что "отношения с заказчиком испорчены" и "9 месяцев и 7 млн потрачено"- это, извините, почти всегда проблемы менеджмента работодателя, а не рядового сотрудника, если в трудовом договоре не было аккуратно и юридически допустимо прописано иное - я лично такого не встречал, это сложно. Где был менеджмент эти 9 месяцев? Это же, блин, просто "чистосердечное признание" некомпетентности менеджера.
При этом я не говорю, что сотрудник - ангелочек с крылышками, тут всякое бывает. Но в ваших "вместо выводах" лично я не увидел реальных способов предотвратить повторение таких ситуаций.
Поверьте, ваша милость, то, что там виднеется, - вовсе не великаны, а ветряные мельницы, а то, что вы принимаете за руки, - это крылья, которые кружатся от ветра и вращают жернова.
В целом автор, конечно, молодец, но по поводу эффективности данной деятельности мне пришла в голову цитата Сервантеса.
У вас в первом комментарии было (ну или по крайней мере мне кажется что было) два независимых утверждения: первое про ГК РФ и Йохансен (если я правильно понимаю, то речь про Scarlett Johansson, т.е. правильнее было бы написать её фамилию как Йоханссон), и второе - про то, что суды в РФ часто не руководствуются законом. Второе утверждение Сергей @Milfgard никак не прокомментировал, а с первым не согласился и спросил ваше мнение как "практикующего юриста" - это словосочетание взято из вашего первого комментария. Во втором комментарии вы, воспользовавшись отсылкой к этому же словосочетанию "практикующий юрист" ответили развитием второго тезиса из первого комментария, но проигнорировали вопрос о первом.
Госрегулирование - плохой и нерабочий способ почти для всего. Не надо его тут.
Некая коммерческая компания не хранит вечно ваши картинки бесплатно и её надо обязать делать это? Следующий шаг - выкинуть за борт этих халявщиков даже не из-за копеек на их содержание, а из-за штрафов регулятора.
Что делать если законы разных стран предписывают прямо противоположное (в одной стране - удалить, а в другой сохранить)? Ах, да, лицам из некоторых стран (например, той в которой я живу) вообще никакой сервис не положен станет.
Что делать, если сервис и юрлицо сервиса больше не существует. Кто должен будет хранить данные?
Там в оригинале квадрат, а не площадь. Maximal Square. Ну и собственно, задача в том, чтобы решить её за O(m*n). Большее time complexity не пройдёт тесты.
Авторам в личку кидал информацию об ошибке, они не исправили.
Вот считать это "завалом крупного проекта" или нет?
Нет, конечно :) Завал проекта, это когда на проектном комитете или на правлении (или на подобном сборище) скажут, что проект завален (что в рамках корпоративной культуры большинства банков практически невозможно - умение признавать ошибки в списке обычно не значится). То что вы описываете, был "серьёзный локальный инцидент, который грозил перерасти в глобальный, но, благодаря подразделению во главе с Имярек И.О., был успешно решён".
На практике в трёх крупных финансовых организациях я неоднократно видел как системы под чуть возросшей нагрузкой заваливались из-за "квадратов". Причём некоторые моменты весьма похожи: несколько "квадратов" на последовательной конкатенации строк, несколько на поиске в списке/массиве/таблице, которые пополняются в цикле. Завалился ли из-за этого какой-то крупный проект? Нет. Если один неосторожный разработчик может завалить неэффективным локальным кодом весь крупный проект, то проблема точно не в разработчике. Были ли заметные финансовые потери? Да. И явно несопоставимые даже с несколькими месяцами работы разработчика.
Странная статья. Не в смысле "плохая", нет. Вроде тот же @Milfgard, вроде и почерк его, те же шуточки, непрерывность контекста с предыдущими публикациями, но меня не покидает ощущение картинки с "Hide the Pain Harold". Не знаю почему.
Найти живую плёночную мыльницу кажется непростой задачей - они уже разложились на плесень да на липовый мёд. А вот топовые зеркальные камеры 1990-х пару лет назад на eBay можно было за очень умеренные деньги взять. Да и сейчас можно, если вопрос с оплатой и доставкой решить. В 2016-2020 годах брал на eBay несколько достаточно экзотичных плёночных вариантов в подарок отцу - все работали.
Модальное окно редактирования ХП с пропорциональным шрифтом по умолчанию... Слеза ностальгии :)
Наличие рабочего экземпляра не отменяет того, что были эти и некоторые другие серии HDD, которые были хуже или сопоставимы с критерием "каждый 10 в первый же год на мусорку", упомянутым в комментарии, на который я ответил.
Поэтому я могу сделать только вывод, что у вас есть старый IBM DTLA, а у меня есть старый Seagate Constellation ES :)
А у меня до сих пор лежит мёртвый DTLA для напоминания. И Seagate ES 1ТБ из "той самой" серии (которая была с косячной прошивкой) есть - он сдох, но был восстановлен.
Сам по себе CXPACKET не является проблемой. По факту это практически только индикатор параллельного выполнения: при параллельном плане почти всегда будет часть веток, которые выполнились быстрее, часть - медленно, поэтому SQL Server часть времени проведёт в CXPACKET. Хорошее объяснение есть тут. Бороться с CXPACKET как таковым обычно не нужно.
С параллельными планами запросов проблемы другие
В распараллеливание отдаётся план до прохождения всех оптимизаций. Чаще всего это очень неэффективный план. И получаются весы: с одной стороны n ядер, но план с с лишними сканами и неэффективными соединениями, с другой - лишние m миллисекунд на оптимизацию и может быть план с нормальными поисками и соединениями.
Очень низкая граница на распараллеливание. 5 "попугаев" - это "как бы 5 секунд на компьютере 2000 года", причём планировщик запросов редко попадает точно в кост, чем бы он ни был. Для 1С я эмпирически пришёл к тому, что Cost Threshold for Parallelism стоит ставить от 100 до 5000 примерно. Так жирные отчеты пойдут параллелиться, а в проведении SQL будет лучше оптимизировать.
(И это упомянуто в статье) По умолчанию параллелизм съедает все ядра. Ну так MS уже лет 10 (как появились сервера с 64 потоками) советует для многоядерных CPU ставить макс. параллельность 8, если нет особых обстоятельств. Ну от себя могу добавить, что какие-то операции, явно сканирующие большие талицы, можно вручную указывать OPTION MAXDOP по максимуму. В том числе, например, построение статистики и перестроение индексов.
1C работает не с уровнем snapshot isolation, а read committed snapshot isolation (RCSI).
40 лет назад мог
То, что компания и сотрудник не сработались - такое бывает. При этом почти всегда и представители компании и сотрудник считают, что неправа другая сторона, но обычно это всё свидетельство ошибок со стороны менеджмента. Причём ошибок, которые лечатся не размытыми "тщательнее отбирать" и "глубже погружать", а вполне стандартными решениями.
Если для вас этот проект ограничен по времени и имеет чёткую цель, то почему у вас сотрудник на обычном бессрочном договоре без рычага в виде существенной премии по итогам? Стандартно это же решается, например, одним из следующих способов:
Срочный договор с большим бонусом в конце (по чёткому критерию)
Бессрочный договор с существенными премиями от результата
Договор ГПХ, если задача "под ключ" - но здесь надо сторить работу не как с сотрудником, а как с подрядчиком
Привлечение сотрудника как аутстафф (да, дороже, но геморрой не ваш)
Решение задачи через аутсорс (но надо быть готовым, что на той стороне не согласятся с тем, что вы не приняли работу - договор, задание и документальное оформление должны быть достаточно чёткими для спора в суде).
Ну и есть еще миллион способов подстелить соломки. Если заранее не побеспокоились, то разойтись на "по соглашению, 2 оклада и отпускные" обычно самое дешёвое и быстрое решение. Внезапные "аттестации" одного сотрудника после угроз и хамства в переписке могут выйти дороже (тут, конечно, лотерея, но я не уверен, что такой "гэмблинг" оправдан).
Все аргументы что "отношения с заказчиком испорчены" и "9 месяцев и 7 млн потрачено"- это, извините, почти всегда проблемы менеджмента работодателя, а не рядового сотрудника, если в трудовом договоре не было аккуратно и юридически допустимо прописано иное - я лично такого не встречал, это сложно. Где был менеджмент эти 9 месяцев? Это же, блин, просто "чистосердечное признание" некомпетентности менеджера.
При этом я не говорю, что сотрудник - ангелочек с крылышками, тут всякое бывает. Но в ваших "вместо выводах" лично я не увидел реальных способов предотвратить повторение таких ситуаций.
В целом автор, конечно, молодец, но по поводу эффективности данной деятельности мне пришла в голову цитата Сервантеса.
У вас в первом комментарии было (ну или по крайней мере мне кажется что было) два независимых утверждения: первое про ГК РФ и Йохансен (если я правильно понимаю, то речь про Scarlett Johansson, т.е. правильнее было бы написать её фамилию как Йоханссон), и второе - про то, что суды в РФ часто не руководствуются законом.
Второе утверждение Сергей @Milfgard никак не прокомментировал, а с первым не согласился и спросил ваше мнение как "практикующего юриста" - это словосочетание взято из вашего первого комментария. Во втором комментарии вы, воспользовавшись отсылкой к этому же словосочетанию "практикующий юрист" ответили развитием второго тезиса из первого комментария, но проигнорировали вопрос о первом.
Госрегулирование - плохой и нерабочий способ почти для всего. Не надо его тут.
Некая коммерческая компания не хранит вечно ваши картинки бесплатно и её надо обязать делать это? Следующий шаг - выкинуть за борт этих халявщиков даже не из-за копеек на их содержание, а из-за штрафов регулятора.
Что делать если законы разных стран предписывают прямо противоположное (в одной стране - удалить, а в другой сохранить)? Ах, да, лицам из некоторых стран (например, той в которой я живу) вообще никакой сервис не положен станет.
Что делать, если сервис и юрлицо сервиса больше не существует. Кто должен будет хранить данные?
У меня нет искры программиста. И никогда не было. Но когда-то давным давно, у знакомого родителей на его работе - была:
Там в оригинале квадрат, а не площадь. Maximal Square. Ну и собственно, задача в том, чтобы решить её за O(m*n). Большее time complexity не пройдёт тесты.
Авторам в личку кидал информацию об ошибке, они не исправили.
Нет, конечно :) Завал проекта, это когда на проектном комитете или на правлении (или на подобном сборище) скажут, что проект завален (что в рамках корпоративной культуры большинства банков практически невозможно - умение признавать ошибки в списке обычно не значится). То что вы описываете, был "серьёзный локальный инцидент, который грозил перерасти в глобальный, но, благодаря подразделению во главе с Имярек И.О., был успешно решён".
В ваши 14 были видеокурсы, php и веб.
Если у вас вход контролируемый, то может и сойдёт. А если это может сделать внешний пользователь, то можно на DoS нарваться.
На практике в трёх крупных финансовых организациях я неоднократно видел как системы под чуть возросшей нагрузкой заваливались из-за "квадратов". Причём некоторые моменты весьма похожи: несколько "квадратов" на последовательной конкатенации строк, несколько на поиске в списке/массиве/таблице, которые пополняются в цикле.
Завалился ли из-за этого какой-то крупный проект? Нет. Если один неосторожный разработчик может завалить неэффективным локальным кодом весь крупный проект, то проблема точно не в разработчике.
Были ли заметные финансовые потери? Да. И явно несопоставимые даже с несколькими месяцами работы разработчика.
Странная статья. Не в смысле "плохая", нет. Вроде тот же @Milfgard, вроде и почерк его, те же шуточки, непрерывность контекста с предыдущими публикациями, но меня не покидает ощущение картинки с "Hide the Pain Harold". Не знаю почему.
(или наоборот - один смайл, но есть закрывающая скобка :-))
А зачем везти на Чукотку? Там сколько торговых центров, на которых надо рекламные акции менять?
Найти живую плёночную мыльницу кажется непростой задачей - они уже разложились на плесень да на липовый мёд. А вот топовые зеркальные камеры 1990-х пару лет назад на eBay можно было за очень умеренные деньги взять. Да и сейчас можно, если вопрос с оплатой и доставкой решить.
В 2016-2020 годах брал на eBay несколько достаточно экзотичных плёночных вариантов в подарок отцу - все работали.