Удаленный запуск Java с помощью PowerShell
когда я запускаю PowerShell в удаленном сеансе (etsn {servername}
), Я иногда не могу запустить Java-процессы, даже самые простые:
[chi-queuing]: PS C:temp> java -cp .hello.jar Hello
Error occurred during initialization of VM
Could not reserve enough space for object heap
Hello.jar
- это "Привет, мир!"приложение, которое должно просто распечатать "Hello" в стандартный вывод.
Итак, вопрос в том, есть ли что-то особенное в запуске процессов на другой стороне сеанса PowerShell? Есть ли что-то особенное о том, как работает Java VM, что может не позволить такое обращение? Память выделяется на удаленном компьютере, верно? Вот показания физической памяти:
[chi-queuing]: PS C:temp> $mem = Get-wmiobject -class Win32_OperatingSystem
[chi-queuing]: PS C:temp> $mem.FreePhysicalMemory
1013000
но, когда я удаленный рабочий стол на сервер и спросить ОС, сколько свободной памяти есть, он говорит 270 МБ физической памяти бесплатно. Дайте мне знать, что вы думаете!
3 ответов
по этому: http://msdn.microsoft.com/en-us/library/aa384372 (VS.85).aspx
MaxMemoryPerShellMB Задает максимальный объем памяти, выделенный для каждой оболочки, включая дочерние процессы оболочки. Значение по умолчанию:150 МБ.
увеличение максимальной памяти на оболочку MB
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="1000"}'
У меня есть другой ответ, чтобы поделиться с вами, ребята. Я оказался в той же ситуации и увеличил память min/max для Java.exe или использование winrm не решили мою проблему.
Я сравнил два сервера: один рабочий и один не рабочий.
Я использовал эту ссылку https://technet.microsoft.com/en-us/library/ff520073%28v=ws.10%29.aspx чтобы проверить мой Windows Management Foundation, который необходим для запуска WINRS, а также удаленного powershell.
в результат: оба сервера под управлением Windows Server 2008 R2. Один сервер под управлением WMF 2.0, один под управлением WMF 3.0.
к моему удивлению, сервер под управлением 2.0 работал, а тот, под управлением 3.0, нет!
мое решение: я обновил 3.0 WMF до 4.0!
просто fyi: у нас были те же симптомы, и у нас было бесконечное исследование, основанное на двух других ответах. Фактическим решением для нас было изменение jdk1.8.0_31-jdk1.8.0_51.