writing mode slows down
-
- Posts: 2
- Joined: Tue Feb 26, 2013 3:08 pm
writing mode slows down
Post by QuintusFixlein »
Hi,
I am using oXygen 14.2 on W7 and I work on xhtml-webpage via webdav connection to a Tomcat, which worked like a charm. Today, somehow, everything in the editor slowed down and its reaction to typing and deleting is really slow, nearly not usable.
I'm not sure if this has anything to do with the webdav connection since I experienced this problem before with DocBook files (and older versions of oXygen).
My suspicion is that it has something to do with the allocated memory, since the files I work with a (relatively) big and oXygen is using up alot of memory, according to
Process Explorer around 900.000K.
Is there a possibility to allocate more memory to the tool, or is my system memory to small?
Any hint to solve this problem is appreciated!
cheers,
Quintus
I am using oXygen 14.2 on W7 and I work on xhtml-webpage via webdav connection to a Tomcat, which worked like a charm. Today, somehow, everything in the editor slowed down and its reaction to typing and deleting is really slow, nearly not usable.
I'm not sure if this has anything to do with the webdav connection since I experienced this problem before with DocBook files (and older versions of oXygen).
My suspicion is that it has something to do with the allocated memory, since the files I work with a (relatively) big and oXygen is using up alot of memory, according to
Process Explorer around 900.000K.
Is there a possibility to allocate more memory to the tool, or is my system memory to small?
Any hint to solve this problem is appreciated!
cheers,
Quintus
Re: writing mode slows down
Hello,
Have you tried to restart the application? Does the problem persist after a restart?
Do you have a 64-bit edition of Windows 7? If you do and also have enough RAM installed (4GB or more), you could install and use the 64-bit edition of Oxygen (has more memory available by default, 1500m).
Note that what you see in Process Explorer or the Windows Task Manager is just the memory used by the Java VM that Oxygen runs inside of. This does not reflect the internal memory usage of Oxygen, just the current size (and most likely upper limit) of the Java VM memory.
Starting with v14 a small widget(optional) is available in the Oxygen status bar (bottom right of the application) that shows you the Java heap usage (instantaneous) and also allows you to force a garbage collection to free up the memory and see a value closer the real heap usage. You can enable this from Options > Preferences, Global, Show memory status. This should give you an idea if/when Oxygen reaches the limits of the available memory.
If you want to increase the memory available to Oxygen you should modify the -Xmx parameter in the oxygen14.2.vmoptions file from the Oxygen installation folder. For the 32-bit edition of Oxygen you should use at most -Xmx1200m (this is a limit imposed by the 32 bit architecture and the Java VM overhead). For the 64-bit edition there is no actual limit. However, in either case, we recommended not allocating more than half of the physical RAM for Oxygen.
Restart the application and verify the amount of memory that is actually available to Oxygen in Help -> About, JVM Memory Used/Total(last row). If the application no longer starts and the error message says that it could not start the JVM then you probably went too far (or specified a bad value) and you should decrease the amount of memory in the 'oxygen14.2.vmoptions' file and try again.
In Windows Vista/7 you will first have to copy the oxygen14.2.vmoptions file to your Desktop(or another folder with write access), modify it there and then copy it back to the Oxygen installation folder replacing the original file.
Note that the parameters from the ".vmoptions" file are only used if you start Oxygen with the "oxygen14.2" launcher(or the desktop shortcut). If you are using the command line startup script "oxygen.bat", you should modify the -Xmx parameter in the script file.
Regards,
Adrian
Have you tried to restart the application? Does the problem persist after a restart?
Do you have a 64-bit edition of Windows 7? If you do and also have enough RAM installed (4GB or more), you could install and use the 64-bit edition of Oxygen (has more memory available by default, 1500m).
Note that what you see in Process Explorer or the Windows Task Manager is just the memory used by the Java VM that Oxygen runs inside of. This does not reflect the internal memory usage of Oxygen, just the current size (and most likely upper limit) of the Java VM memory.
Starting with v14 a small widget(optional) is available in the Oxygen status bar (bottom right of the application) that shows you the Java heap usage (instantaneous) and also allows you to force a garbage collection to free up the memory and see a value closer the real heap usage. You can enable this from Options > Preferences, Global, Show memory status. This should give you an idea if/when Oxygen reaches the limits of the available memory.
If you want to increase the memory available to Oxygen you should modify the -Xmx parameter in the oxygen14.2.vmoptions file from the Oxygen installation folder. For the 32-bit edition of Oxygen you should use at most -Xmx1200m (this is a limit imposed by the 32 bit architecture and the Java VM overhead). For the 64-bit edition there is no actual limit. However, in either case, we recommended not allocating more than half of the physical RAM for Oxygen.
Restart the application and verify the amount of memory that is actually available to Oxygen in Help -> About, JVM Memory Used/Total(last row). If the application no longer starts and the error message says that it could not start the JVM then you probably went too far (or specified a bad value) and you should decrease the amount of memory in the 'oxygen14.2.vmoptions' file and try again.
In Windows Vista/7 you will first have to copy the oxygen14.2.vmoptions file to your Desktop(or another folder with write access), modify it there and then copy it back to the Oxygen installation folder replacing the original file.
Note that the parameters from the ".vmoptions" file are only used if you start Oxygen with the "oxygen14.2" launcher(or the desktop shortcut). If you are using the command line startup script "oxygen.bat", you should modify the -Xmx parameter in the script file.
Regards,
Adrian
Adrian Buza
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
-
- Posts: 2
- Joined: Tue Feb 26, 2013 3:08 pm
Re: writing mode slows down
Post by QuintusFixlein »
Well, what can I say?
Brillant, comprehensive and successfull answer and suggestions.
Garbage collection did the trick, thanks a lot!
regards,
Quintus
Brillant, comprehensive and successfull answer and suggestions.
Garbage collection did the trick, thanks a lot!
regards,
Quintus
Re: writing mode slows down
Hi,
I'd like to point out that manual garbage collection from Oxygen doesn't actually do anything to resolve or improve the insufficient memory problems, it just gives you a better picture of how much memory is actually used by the application.
The manual garbage collection simply triggers the Java VM to perform a memory cleanup that would eventually be triggered anyway when the Java VM runs out of usable (clean) memory. So while the Java VM automatic garbage collection is lazy (it cleans up only if it has to), it always cleans up all the memory it can, before running out of memory. This is why you usually feel that significant slowdown when running close to the Java VM memory limit, the automatic garbage collector is hard at work trying to scrape up any memory it can to make room for the memory allocation requests.
Regards,
Adrian
I'd like to point out that manual garbage collection from Oxygen doesn't actually do anything to resolve or improve the insufficient memory problems, it just gives you a better picture of how much memory is actually used by the application.
The manual garbage collection simply triggers the Java VM to perform a memory cleanup that would eventually be triggered anyway when the Java VM runs out of usable (clean) memory. So while the Java VM automatic garbage collection is lazy (it cleans up only if it has to), it always cleans up all the memory it can, before running out of memory. This is why you usually feel that significant slowdown when running close to the Java VM memory limit, the automatic garbage collector is hard at work trying to scrape up any memory it can to make room for the memory allocation requests.
Regards,
Adrian
Adrian Buza
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
Jump to
- Oxygen XML Editor/Author/Developer
- ↳ Feature Request
- ↳ Common Problems
- ↳ DITA (Editing and Publishing DITA Content)
- ↳ SDK-API, Frameworks - Document Types
- ↳ DocBook
- ↳ TEI
- ↳ XHTML
- ↳ Other Issues
- Oxygen XML Web Author
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Content Fusion
- ↳ Feature Request
- ↳ Common Problems
- Oxygen JSON Editor
- ↳ Feature Request
- ↳ Common Problems
- Oxygen PDF Chemistry
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Feedback
- ↳ Feature Request
- ↳ Common Problems
- Oxygen XML WebHelp
- ↳ Feature Request
- ↳ Common Problems
- XML
- ↳ General XML Questions
- ↳ XSLT and FOP
- ↳ XML Schemas
- ↳ XQuery
- NVDL
- ↳ General NVDL Issues
- ↳ oNVDL Related Issues
- XML Services Market
- ↳ Offer a Service