Is there an artifactory 7 release containing a fix for RTFACT-26825 (memory leak and timeouts using nuget-repositories) - artifactory

In our company we recently upgraded to artifactory-pro:7.38.10 from version 6. To cleanup old artifacts we are using lavatory which runs an aql-search to identify the artifacts to be removed by filtering them by the date. This worked without issues our previous installation based on artifactory 6. Now after the upgrade artifactory frequently crashes with an OutOfMemoryError and the instance seems to require either significantly more memory than before or there is a memory leak. After further investigation it turned out that when problem is caused by running the aql-search and the memory usage jumps from 4 GB to over 10 GB. That's +6 GB for something that hasn't changed.
After searching for known issue I found https://www.jfrog.com/jira/browse/RTFACT-26825 which is resolved and might solve our problem but there is no version specified containing a fix. Since there is a workaround and the issue was fixed, I expect that there must be a release.
Is there already a release containing a fix?

The JIRA that you are referring to is fixed in the Artifactory version 7.38.0. So mostly, that should not be causing an issue as you are in higher version than 7.38.0.
In order to confirm, you may try the below. Add the system property to $JFROG_HOME/artifactory/var/etc/artifactory/artifactory.system.properties file and restart Artifactory for changes to take effect:
artifactory.nuget.v2.search.page.size=1000
Alternatively, you may put all the Nuget Devexpress repositories as offline. Now, check if you are encountering the memory issue. If you are not encountering this issue, maybe there is a regression issue. But according to my assumption, your server needs more resources as there are a lot of microservices introduced in Artifactory 7, when compared to Artifactory 6.
Please check if you are satisfying the resources requirement as mentioned in this page. In that case, you would need to tune your Artifactory as per this article.

Related

Cannot find vpd.properties when running uninstall.cmd for EPM 11G R1 Uninstall

There was a similar question on this 5 years ago - however it did not seem to have any conclusion.
https://community.oracle.com/tech/apps-infra/discussion/4112075/epm-uninstall-not-working
I am attempting to uninstall cleanly EPMSystem 11G R1 (old EPM Essbase Foundation) and having issues.
I have looked at several Oracle Support articles for this - namely the following below - but these do not detail manual deletion to mitigate the error I am getting as they all seem to suggest running the uninstall.
How to Uninstall Hyperion Enterprise Performance Management (EPM) (Doc ID 1265740.1)
Perform a Clean Uninstall of EPM 11.1.2 on Microsoft Windows (Doc ID 1140553.1)
The document DOC ID 1140553.1 suggests to use is not able to be found.
Going into the details - see attached screenshots.
It seems that the de-install has no concept of how the vpd.properties exists - even though it is definitely there in its folder/directory structure.
When attempting to run un-install via add/remove programs - it just runs the same .cmd and fails to execute.
I am aware Ora Central Inventory replaces vpd.properties (which defines the installed products) but in this case the jars seem to just want to see the vpd.properties (cannot open up the binary to see the location it seems to want vpd.properties to exist at).
Anyone see this issue before? I do not want to simply just delete the folders as that will mean I will need to also find all the registry keys etc that may be removed through clean uninstall.
If there is a manual process that works - willing to do it - but tried a lot of things to fix this error to no avail

Kolla-ansible too many open files

I am having an issue with a relatively small openstack cluster deployed with kolla-ansible. The issue is that after a few days the controllers stop working. When I go into the docker container logs, I see in all of them that there are Too Many Open Files. I have tried changing limits.conf sysctl max files for processes and user. After all of that, the issue still shows up.
One interesting thing is that this was not happening until I had to reboot all of the controllers. I rebooted them because I needed to increase the amount of ram that they have after they died swapping. My first thought was that kolla-ansible is setting a configuration after running deploy, but I can't seem to find any point in the repo when kolla-ansible is changing ulimits or other.
Any theories what could cause this? Would it be related to increasing ram? Should I run reconfigure/deploy on each controller? I've tried looking in kolla-ansible's docs and forums and couldn't see where anyone else was having this issue.
Update this hasn't been fixed yet:
I submitted a bug report, https://bugs.launchpad.net/kolla-ansible/+bug/1901898
I don't know your used versions of Kolla-Ansible and your Linux, but your problem seems really related to this one:
On Ubuntu 16.04, please uninstall lxd and lxc packages. (An issue exists with cgroup mounts, mounts exponentially increasing when restarting container) (source: docs.openstack.org/kolla-ansible/4.0.0/quickstart.html)
I had this problem with the exponentially growing number of mount-pointers after the restart of my docker-containers too. My single-node test-deployment had become very slow based on this problem, but I can't remember at the moment, that I would had the same error with too many open files.
You can delete the packages with apt-get remove lxc-common lxcfs lxd lxd-client. I had done this fix together with a complete reinstallation of the kolla-ansible installation, so I don't know, if this also helps with an already existing installation. You should also use docker-ce instead of the docker from the apt-repos.
This was fixed with a workaround in bug https://bugs.launchpad.net/keystonemiddleware/+bug/1883659 problem was neutron server was keeping memcached connections open and not closing them until the memcached container reached too many files open. There is a work around mentioned in the bug link.

Do I need to install all previous Cumulative updates (cu) for BizTalk?

I recently installed CU9 to BizTalk 2010. Microsoft site (https://support.microsoft.com/en-us/kb/3136004) claims that all previously CU are included in latest CU.
BizTalk Server uses a cumulative update (CU) model for providing fixes and updates. Each cumulative update includes new updates in addition to all the updates that were included in previous cumulative updates
Now I have problem with deployment ("Error saving map. Stored procedure returned non-zero result." error message when you deploy the BizTalk Server 2010 applications in BizTalk Server 2010 Administration Console") supposed to be fixed in CU4.(https://support.microsoft.com/en-us/kb/2667310)
So do I need to install all CUs from 1 - latest (for BizTalk 2010) to be fully upgraded?
You do not need to install all of them, the latest is just fine. They are cumulative as is stated.
That being said: have you tried uninstalling the latest CU (CU9) and installing CU4 instead? I assume you had no CU's installed before?
Unfortunately, lately Microsofts track records in relation to BizTalk CU's is not something to be proud of... There were quite a few issues with CU's already. It is not unthinkable that some CU after CU4 reintroduced the issue.
Also: the specific issue you are mentioning is something that was supposedly being fixed in CU4. However, this is just one particular case that was solved. There are still other remaining cases which have not been fixed yet.
Problem solved. It turned out that this App is using resources from another app that was not fully upgraded and one schema was missing in it. After deploying/upgrading that shared application everything went well.

Unable to install any release version of Meteor on Win 10

I've been using 1.1 on Win 10. When 1.2 came out, I tried upgrading but it actually falled back to 0.3. According to sashko a reinstall was necessary, which solved the problem for some. However, nothing happened when I uninstalled and rerun the installer. No files were actually modified. Deleting the %localappdata%/.meteor folder didn't help either. As the installer would no longer put anything there.
The farthest I could get is to get a dev build with a git clone, but I'd like to use a release version either 1.1 or 1.2. Otherwise I'm not able to update my project with a checkout meteor build.
Wrote a bunch of comments on other threads but none of the suggestions helped thus far, so I thought this deserves a new separate thread.
The solution was to clean the registry of meteor entries.
Credit goes to avalanche1 at: https://forums.meteor.com/t/windows-install-uninstall-hell/2375/7

How can I uninstall Win32 assemblies and cleanup WinSxS?

After a lot of trial and error (mostly due to lack of documentation and examples) I have managed to create MSI installers that install custom DLLs to WinSxS as side-by-side assembly. There is only one problem: Uninstalling leaves all files (DLLs, manifests and catalogs) in the WinSxS directory. How can or should I best clean that up? I know for sure that nothing else references it.
I have read somewhere that WinSxS has a self-scavenging process that cleans up over time but I could not find more information about that. Can you manually invoke this to clean up stuff?
The only other way I see is manually deleting those bits. First you have to change the owner of all files (assembly, catalog, manifest and their respective directory) from SYSTEM to an administrator account, adjust the permissions and delete them. There are also pieces left in the registry (I think HKLM\COMPONENTS\DerivedData\Components may be one place), but since WinSxS should be treated as opaque it is hard to find any information.
Scavenging isn't exposed anywhere that I know of. I'm not even sure when it is kicked off automatically. Maybe on uninstall of a service pack? Maybe some tool admins can run? I really forget.
Anyway, my suggestion is don't fight it. There are so many twisty turns down there that it just isn't worth trying to get the disk space back. Once uninstalled the bits still in the SxS cache will not be activated so they are just wasting space.
It's a dumb design but blame Microsoft and don't try to overcompensate.
Here is an article, it's kinda complete guide to WinSxS.
So, shortly, you can only uninstall some components (all their versions are in this folder), and you can run Service Pack bridge burning utility (in Vista it is named VSP1CLN.EXE and shipped with SP1). Note, that after execution, you shouldn't be able to uninstall SP or any components to state, prior to SP release date.
No-one is convinced you can - short of a complete reinstall, your bloaty WinSxS directory is there to stay.
There's been a long "discussion" of the problem on technet.
There is no documentation of the format, or any instructions how to remove files that are no longer needed - MS seems to think that disc space is cheap. There is a self-scavenging feature, but no-one's convinced it works, or if it does, it is very conservative (as you'd hope as you don't want it to break your OS)
You can tell is the scavenger is working by checking the "C:\Windows\winsxs\Temp\PendingDeletes." folder, as this is where files are moved by windows update or an installer moves them to - the scavenger just deletes the files in here.
You'll notice that after you uninstall your assembly, while the files are still there, they can no longer be bound to - so they are just "staged", or cached, but not really installed.
Rob & gbjbaanb are correct - you cannot manually invoke a scavenge yourself. Don't try to delete the files yourself - there are multiple places in the registry where they are registered, DerivedData\Components being only one of the many references.
I think the rule for Vista is scavenging is kicked off by the TrustedInstaller service after 10 minutes of machine inactivity, after the last servicing operation (service pack, hotfix, etc). But it's very fickle, so it doesn't run as often as it should. So just be patient, and the files will disappear on their own.
Well i was having some issues as i have an 80GB SSD for my windows and the WinSxs folder was about 12gb's
I was searching the net and i found this command:
DISM.exe /online /Cleanup-Image /spsuperseded
And now my WinSxs is 7gb which was wonderful news.
There are a few updates regarding the cleanup method that apply to newer OS. Check http://www.karafilis.net/winsxs-cleanup

Resources