Нужно больше практики

Курсы курсами, а вот практики в решении проблем технологического характера очень не хватает. Возможно кто-то из вас сможет помочь с моей бедой. Поэтому решил провести эксперимент - прием заявок на диагностику проблем производительности. Для участия необходимо перейти по ссылке "Ускорение 1С" в шапке блога и зарегистрировать обращение.

Предполагается следующий формат:
- до четырех часов безвозмездной работы по вашей проблеме;
- основные работы будут проводиться по вечерам или в выходные;
- отчет будет опубликован в блоге.

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

bash, еще bash, еще много-много bash

А на ловца и зверь бежит, коллеги. Буквально недавно эпизодически bash'ил подведомственный техжурнал и делал заготовки скриптов. И тут свершилось - двухнедельный проект по анализу текущих проблем производительности. Без ограничений не обошлось, в лучших традициях жанра. Конфигурация УПП 1.3 - соответственно, древняя БСП, где подсистема оценки производительности еще на перечислениях. На продуктив ходить только под присмотром, самостоятельно ничего не менять, ничего не запускать. ЦУП нельзя, как сказали, уже пробовали - сбор данных тормозит систему. Заказчик привел адекватные аргументы в пользу поставленных ограничений. В итоге, из доступных инструментов остались логи технологического журнала и счетчики производительности, которые складываются на отдельный тестовый сервер. Там же развернута копия базы. Если бы не скрипты, то тогда вообще непонятно бы было, что со всем этим делать.

grep всему голова

При разборе проблем, связанных с эксплуатацией 1С, анализ технологического журнала играет немаловажную роль. При этом объемы данных для анализа могут достигать приличных размеров. Что, в свою очередь, приводит к необходимости использования инструментов, обеспечивающих приемлемую скорость разбора файлов журнала. Например, использование утилит bash. В качестве вводной статьи могу порекомендовать ознакомиться с публикацией на ИТС. Практическое применение рассмотрим на примере анализа взаимоблокировок.

Где моя отладка, чувак?

Обычно, когда отваливается отладка, первоначальными подозреваемыми становятся брандмауэр или антивирус. Соответственно, самый простой способ проверить их влияние на возникшую проблему - отключить их и запустить отладочный сеанс. Но в некоторых случаях проблема может скрываться совершенно в другом месте. Общая рекомендация - не начинать бездумно применять все подряд "шаманские" способы из интернета, а в необходимом объеме собрать техническую информацию о возникающих событиях и ошибках, сопровождающих запуск отладки на исследуемой машине.