filecheck .ru
Вот так, вы сможете исправить ошибки, связанные с erl.exe
Информация о файле erl.exe
Описание: erl.exe не является необходимым для Windows. Erl.exe находится в подпапках «C:\Program Files». Известны следующие размеры файла для Windows 10/8/7/XP 120,320 байт (50% всех случаев), 119,808 байт или 20,992 байт. 
У процесса нет видимого окна. Нет информации по файлу. Это не системный файл Windows. Процесс использует порт, чтобы присоединится к сети или интернету. Поэтому технический рейтинг надежности 66% опасности.
Программа Erlang OTP 18 или Erlang OTP 21 может быть удалена в Панели управления в разделе программы и компоненты.
Важно: Некоторые вредоносные программы маскируют себя как erl.exe. Таким образом, вы должны проверить файл erl.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.
Комментарий пользователя
Лучшие практики для исправления проблем с erl
Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.
erl сканер
Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.
Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.
Reimage бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.
Борьба за производительность или кто отнимал процессорное время
Началось все с «Неваляшки». О том, что это такое и для чего это было надо описано тут: http://habrahabr.ru/company/oktell/blog/108726/. То есть, мы имели четыре работающих сервера call-центра, одинаково настроенных и с примерно одинаковой конфигурацией внешних и внутренних линий, пользователей и настройкой внутренней БД. На каждый из серверов со стороны оператора связи поступала равномерная звонковая нагрузка, но сервера реагировали на это по разному!
N Конфигурация сервера и операционная система
1 T1300 @ 1.66 1 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP1 32 bit
2 Intel Core Duo E8400 @ 3000 4 Гб ОЗУ, Windows 2003 Standard Ed.SP1 32 bit
3 Intel Pentium 4 3GHz 2 Гб ОЗУ, Windows 2003 Standard Ed. SP2 32 bit
4 E3400 @ 2.60 2 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP2 32 bit
Столкнулись с жалобами на качество связи. Причем, жаловались не на каждый звонок, а на «некоторые». Жаловались на «кваки», очень характерные для VoIP телефонии. Довольно оперативно было выяснено, что причиной появления «кваков» было непредсказуемый рост занятости процессора на одном (первом) из серверов call-центр при возрастании нагрузки. И это при всем притом, что другие сервера такой нагрузки вообще не замечали, и никакого роста нагрузки на процессор при таком же количестве вызовов не наблюдалось. Даже, несмотря на то, что первый сервер был значительно слабее всех остальных, такой картины — роста занятости процессора до 100% — наблюдаться не должно было.
Не стоит, наверное, говорить, что мы прошли стандартный путь «протирки фар», «пинания колес» и пр. В конечном итоге пришли к мнению, что ни настройки самого call-центр, ни его СУБД, на поведение сервера не влияет. Отправной точкой для понимания сущности проблемы послужил тот факт, что в диспетчере задач в списке процессов ни один из процессов не занимал процессорного времени, вместе с тем, на мониторинге быстродействия хронология загрузки процессора показывала непрерывную загрузку процессора ядра на уровне 20%.
Задались целью получить ответ на вопрос чем же занято ядро в том случае, когда нагрузки на все остальные сервисы отсутствуют. Process Explorer — штатная утилита от Microsoft — подсказала, что основным потребителем ресурсов является «Hardware Interrupts». Для дальнейшего анализа причин такого потребления была скачана другая штатная утилита от Microsoft — «Kernrate View». Как и было описано в рекомендациях по использованию, в командной строке выполнили «C:\Program Files\KrView\Kernrates\Kernrate_i386_XP.exe >> log.txt» и, спустя некоторое время, нажав Ctrl-C, остановили. Получили файл log.txt, содержащий информацию вида:
/==============================\
\==============================/
Date: 2010/12/08 Time: 1:09:14
Machine Name: RESERVCC
Number of Processors: 1
PROCESSOR_ARCHITECTURE: x86
PROCESSOR_LEVEL: 6
PROCESSOR_REVISION: 0e08
Physical Memory: 1015 MB
Pagefile Total: 2450 MB
Virtual Total: 2047 MB
PageFile1: \??\C:\pagefile.sys, 1524MB
OS Version: 5.2 Build 3790 Service-Pack: 1.0
WinDir: C:\WINDOWS
Kernrate User-Specified Command Line:
Kernrate_i386_XP.exe
Kernel Profile (PID = 0): Source= Time,
Using Kernrate Default Rate of 25000 events/hit
P0 K 0:00:36.671 (28.5%) U 0:00:09.671 ( 7.5%) I 0:01:22.343 (64.0%) DPC 0:00:29.484 (22.9%) Interrupt 0:00:00.281 ( 0.2%)
Interrupts= 136809, Interrupt Rate= 1063/sec.
Total Profile Time = 128687 msec
Total Avg. Rate
Context Switches, 609407, 4736/sec.
System Calls, 5078088, 39461/sec.
Page Faults, 119817, 931/sec.
I/O Read Operations, 11671, 91/sec.
I/O Write Operations, 209479, 1628/sec.
I/O Other Operations, 229216, 1781/sec.
I/O Read Bytes, 39981700, 3426/ I/O
I/O Write Bytes, 19240135, 92/ I/O
I/O Other Bytes, 7130204725, 31107/ I/O
— Results for Kernel Mode:
— OutputResults: KernelModuleCount = 99
Percentage in the following table is based on the Total Hits for the Kernel
Time 44651 hits, 25000 events per hit — Module Hits msec %Total Events/Sec
intelppm 27457 128685 61 % 5334149
hal 12284 128685 27 % 2386447
ntkrnlpa 2868 128685 6 % 557174
win32k 525 128685 1 % 101993
alder9xp 427 128685 0 % 82954
tcpip 254 128685 0 % 49345
Ntfs 251 128685 0 % 48762
afd 120 128685 0 % 23312
RDPDD 109 128685 0 % 21175
e1e5132 109 128685 0 % 21175
iaStor 97 128685 0 % 18844
NDIS 39 128685 0 % 7576
RDPWD 31 128685 0 % 6022
fltMgr 26 128685 0 % 5051
amon 12 128685 0 % 2331
termdd 10 128685 0 % 1942
CLASSPNP 10 128685 0 % 1942
ftdisk 7 128685 0 % 1359
ipsec 3 128685 0 % 582
Npfs 2 128685 0 % 388
USBPORT 2 128685 0 % 388
volsnap 2 128685 0 % 388
TDTCP 1 128685 0 % 194
rdbss 1 128685 0 % 194
ws2ifsl 1 128685 0 % 194
netbt 1 128685 0 % 194
watchdog 1 128685 0 % 194
PartMgr 1 128685 0 % 194
Далее определяем какой именно драйвер загружает процесс «Hardware Interrupts». В списке лога «Kernrate View» он будет верхним, и рядом в процентах будет показана его доля занимания ядра. Тут стоит обратить внимание, что проценты показывают не общий процент от загрузки системы, а процент загрузки серверного ядра драйверами.
Определили, что этим драйвером является Intelppm (Intel processor power manager). Дальше — google нам в помощь. Интернет велик, могуч и безграничен. Довольно быстро поняли, что проблема с Intelppm возникает, не так уж и часто, вместе с тем, мы были не одни столкнувшиеся с такой бедой. Результат не замедлил себя обнаружить, нашлась статья, в которой не только описывается сама проблема, но и обозначается путь ее решения (Постоянный адрес оригинала статьи тут: http://www.osp.ru/text/print/302/5818429.html)
Далее следуя рекомендациям Стивена Догерти понимаем, что intelppm, является драйвером управления электропитанием процессора, который не нужен на сервере, где питание от аккумулятора и не используется вовсе. Вариантов решений было предложено несколько: переустановка, обновление или остановка неисправного драйвера. Какой варианты выберете вы — смотрите сами, вполне логично тут следовать оригинальным рекомендациям Догерти.
Мы полезли в реестр. Данные драйвера процессора Intel находятся в разделе реестра HKEY_LOCAL_MACHINE/SYSTEM/Current Control Set/Services/intelppm. Для отключения драевера intelppm изменили значение параметра Start с 1 на 4. Специалисты Microsoft, конечно, рекомендуют делать резервную копию реестра, но мы то с вами русские люди, да и что там один параметр поменять с 1 на 4. 
Рестарт помог убедиться, что загрузка процессора в среднем находится в пределах 60-70% даже при полной(!) загрузке сервера call-центр звонками.
Очень интересно выглядит при этом диспетчер устройств: 
Жалуется, ябедничает, плачет: «Драйвер для этого устройства был отключен. Возможно, необходимые функции исполняет другой драйвер. (Код 32), Нажмите кнопку „Диагностика“, чтобы запустить мастер диагностики для данного устройства.» Но на безопасность полетов это уже не влияет 😉
Erlang, rebar3 и установка сервиса под Windows
Как заставить Erlang релиз работать как сервис под Windows. Оставим за кадром вопрос зачем это делать. Просто иногда это нужно. Так что сосредоточимся на КАК. Что-бы было еще сложнее поставим себе задачу делать это с помощью wixtoolset.
Эта заметка некая шпаргалка самому себе. Хотя я очень надеюсь что никогда не пригодится. Поехали.
Представим себе что файлы мы как-то поставили и ран-тайм с собой принесли. Запуск апликации в виде консоли срабатывает и теперь надо оформить запуск приложения в виде сервиса. Если есть проблемы уже на этом этапе — пишите мне, я там как-раз топтался.
Итак, Тут нас ждут несколько веселых подводных камней. Мы как-бы можем запустить скрипт ИМЯ-АПЛИКАЦИИ.cmd install. И это даже сработает. Но есть 2 недостатка — вскакивает черный экран и сервис не удаляется при удалении апликации.
Так что перейдем к тому чего будет нехватать:
1) Файл erl.ini в директории erts-НОМЕР\bin. Его содержимое после установки содержит пути машины где релиз собирали. Его содержимое надо менять. И в путях надо ставить двойные слеши.
2) Запускается сервис с помощью файла erlsrv.exe. Это часть рантайма, тут все хорошо. Надо не забыть взять его с собой.
3) erlsrv.exe расчитывает найти файл start.boot по адресу releases\VERSION. А его там нет. И надо скопировать его
4) erlsrv.exe хранит параметры сервиса в регистре. И их надо дописать самим.
Например нашу чудо апликацию зовут erlang_service. Пишем в регистр:
—rootdir — место где установлена апликация. Именно так. Если взять например [ROOT] — id самой директории, то ничего не будет работать, так как в конце будет слеш. А оно его сбивает с толку.
InternalServiceName Value=»erlang_service» — под таким именем будем ставить сервис.
SName — это erlang short name
[ROOT] — ID директории в которой лежат наши файлы.
В результате имеем сервис который автоматически ставится, останавливается и корректно удаляется.
erlsrv
This utility is specific to Windows NT/2000/XP (and later versions of Windows). It allows Erlang emulators to run as services on the Windows system, allowing embedded systems to start without any user needing to log on. The emulator started in this way can be manipulated through the Windows services applet in a manner similar to other services.
Notice that erlsrv is not a general service utility for Windows, but designed for embedded Erlang systems.
erlsrv also provides a command-line interface for registering, changing, starting, and stopping services.
To manipulate services, the logged on user is to have administrator privileges on the machine. The Erlang machine itself is (default) run as the local administrator. This can be changed with the Services applet in Windows.
The processes created by the service can, as opposed to normal services, be «killed» with the task manager. Killing an emulator that is started by a service triggers the «OnFail» action specified for that service, which can be a reboot.
The following parameters can be specified for each Erlang service:
StopAction
Tells erlsrv how to stop the Erlang emulator. Default is to kill it (Win32 TerminateProcess), but this action can specify any Erlang shell command that will be executed in the emulator to make it stop. The emulator is expected to stop within 30 seconds after the command is issued in the shell. If the emulator is not stopped, it reports a running state to the service manager.
OnFail
Can be one of the following:
reboot
The Windows system is rebooted whenever the emulator stops (a more simple form of watchdog). This can be useful for less critical systems, otherwise use the heart functionality to accomplish this.
restart
Makes the Erlang emulator be restarted (with whatever parameters are registered for the service at the occasion) when it stops. If the emulator stops again within 10 seconds, it is not restarted to avoid an infinite loop, which could hang the Windows system.
restart_always
ignore (the default)
Reports the service as stopped to the service manager whenever it fails; it must be manually restarted.
Machine
Specifies an extra environment for the emulator. The environment variables specified here are added to the system-wide environment block that is normally present when a service starts up. Variables present in both the system-wide environment and in the service environment specification will be set to the value specified in the service.
WorkDir
Priority
The process priority of the emulator. Can be one of the following:
realtime
Not recommended, as the machine will possibly be inaccessible to interactive users.
high
Can be used if two Erlang nodes are to reside on one dedicated system and one is to have precedence over the other.
Can be used if interactive performance is not to be affected by the emulator process.
default (the default> SName or Name
Specifies the short or long node name of the Erlang emulator. The Erlang services are always distributed. Default is to use the service name as (short) nodename.
DebugType
Can be one of the following:
reuse
console
none (the default)
The output of the Erlang shell is discarded.
The console option is not intended for production. It is only a convenient way to debug Erlang services during development.
The new and reuse options might seem convenient in a production system, but consider that the logs grow indefinitely during the system lifetime and cannot be truncated, except if the service is restarted.
In short, the DebugType is intended for debugging only. Logs during production are better produced with the standard Erlang logging facilities.
InternalServiceName
Specifies the Windows-internal service name (not the display name, which is the one erlsrv uses to identify the service).
This internal name cannot be changed, it is fixed even if the service is renamed. erlsrv generates a unique internal name when a service is created. It is recommended to keep to the default if release handling is to be used for the application.
The internal service name can be seen in the Windows service manager if viewing Properties for an Erlang service.
Comment
A textual comment describing the service. Not mandatory, but shows up as the service description in the Windows service manager.
The naming of the service in a system that uses release handling must follow the convention NodeName_Release, where NodeName is the first part of the Erlang node name (up to, but not including the «@») and Release is the current release of the application.
The set and add commands modifies or adds an Erlang service, respectively. The simplest form of an add command is without any options in which case all default values (described above) apply. The service name is mandatory.
-st[opaction] [ ]
The action to take when the Erlang emulator stops unexpectedly. Default is to ignore.
-m[achine] [ ]
-w[orkdir] [ ]
The initial working directory of the Erlang emulator. Defaults to the system directory.
The priority of the Erlang emulator. Default to the Windows default priority.
Specifies where shell output is to be sent. Default is that shell output is discarded. To be used only for debugging.
-i[nternalservicename] [ ]
-c[omment] [ ]
Specifies a textual comment describing the service. This comment shows up as the service description in the Windows service manager.
These commands are only added for convenience, the normal way to manipulate the state of a service is through the control panels services applet.
The start and stop commands communicates with the service manager for starting and stopping a service. The commands wait until the service is started or stopped. When disabling a service, it is not stopped, the disabled state does not take effect until the service is stopped. Enabling a service sets it in automatic mode, which is started at boot. This command cannot set the service to manual.
Removes the service completely with all its registered options. It is stopped before it is removed.
If no service name is specified, a brief listing of all Erlang services is presented. If a service name is supplied, all options for that service are presented.
Ошибка установки Windows x64 RabbitMQ с переменной среды Erlang (ERLANG_HOME)
Я спрашиваю /отвечаю на этот вопрос, потому что он повесил меня и вероятно, у кого-то еще будет такая же проблема.
Установка RabbitMQ x64 v2.8.6 на Windows Server 2008 x64.
После установки Erlang с использованием места установки по умолчанию в C: \ Program Files \ erl5.9.2 я пытаюсь запустить сервер с помощью rabbitmq-service.bat. Сбой:
8 ответов
редактируя этот файл rabbitmq_server.bat, вы можете увидеть примерно в строке 48 или около того, есть проверка, найден ли файл erl.exe, но путь указан неверно:
Я просто жестко прописал путь к своему файлу erl.exe:
1- Установите переменную среды:
Имя переменной: ERLANG_HOME
Значение переменной: C:\Program Files (x86)\erl6.4
примечание: не включайте bin на предыдущем шаге.
2- Добавьте %ERLANG_HOME%\bin в PATH переменная среды:
Имя переменной: PATH
Значение переменной: %ERLANG_HOME%\bin
Это хорошо работает.
Интересно, что это сработало для тебя. В Erl5.9.2 есть запись о двух ошибках, которые приводят к неполной установке, когда %ERLANG_HOME%\bin не установлен.
Любой из * Установлен 64-битный Erlang на 32-битной машине * «Невозможно запустить программу, так как MSVCR100.dll отсутствует на вашем компьютере.»
Попробуйте 5.9.1 или любую другую версию. Они также упоминают о том, что будущие версии установщика будут предупреждать вас в случае сбоя.
Я попал в такую же проблему. Я решил это, выполнив три изменения, как указано ниже.
У меня так получилось.
Что происходит, так это то, что установщик RabbitMQ 3.6.9 удаляет переменную среды ERLANG_HOME из системы, удаляя старую версию RabbitMQ. Затем, когда он переходит к шагу установки, он не возвращает обратно переменную ERLANG_HOME. Затем командные файлы, которые запускают RabbitMQ, не могут найти Erlang. Они пытаются найти домашний каталог Эрланга, используя «where.exe», но он всегда терпит неудачу после обновления.
RabbitMQ довольно неуклюж в Windows.
Я только что упомянул здесь ту же проблему. Я установил otp_win64_R15B02 на компьютере с Windows 7, и все работало отлично, но я использовал тот же установщик на сервере Windows 2008, и каталог bin не был создан. Затем я удалил otp_win64_R15B02 и загрузил otp_win64_R15B02_with_MSVCR100_installer_fix, и каталог bin был создан.
Я подозреваю, что причина, по которой он работал в моей системе Windows 7, заключается в том, что у меня установлена Visual Studio, и необходимые библиотеки уже были доступны, что позволило корректно работать установщику otp_win64_R15B02.
О, и если вы устанавливаете Erlang для запуска RabbitMQ, установка RabbitMQ будет успешной с испорченным установщиком, но установка otp_win64_R15B02_with_MSVCR100_installer_fix после того, как RabbitMQ не будет работать, просто удалите и переустановите RabbitMQ, чтобы решить эту проблему.
Я думаю, что это проблема кодирования в Windows. Я вижу правильное значение, но я пишу echo% ERLANG_HOME% на консоли, значение идет со знаком вопроса. Эти шаги исправить это.
окно переменной окружения 1.go
2.редактируйте элемент ERLANG_HOME
3. скопируйте значение, откройте блокнот и вставьте туда
4. снова скопируйте в блокнот и вставьте в окно редактирования
5.применить и выйти из окна
6.Закройте инструменты командной строки и снова откройте
