I am facing an issue with the IBM cloundant. I am using the 1GB free plan.
I have this dashboard showing me that I am using about 40mb from the plan, however, when I look my monitoring screen I see that my storage is using almost 700mb. What I can do to find where are all these huge data and delete them?
Below is the screenshot of my dashboard showing how much I am using in ALL my dbs
And here are my Monitoring screen saying that I am using much more
This appears to be a bug in the Cloudant dashboard. The numbers in the database list aren't reported correctly. I've raised this with the Cloudant development team. You can check the db data volume by a GET to the db name:
Stefans-MacBook-Pro:SAPI stefan$ acurl 'https://skruger.cloudant.com/aviation' | jq .
{
"update_seq": "68396-[stuff]wo4M",
"db_name": "aviation",
"purge_seq": 0,
"sizes": {
"file": 88201146,
"external": 88457573,
"active": 60042977
},
What you are looking for is the sizes.external value.
EDIT Jun 24, 2021 -- a dashboard fix for this was deployed today.
Related
We have Microsoft Dynamics 365 (CRM) on premise version.
This instance is used by around 100 users and there are 15+ custom applications written in .Net, which consumes CRM Web service to perform CRUD operations.
For fetching data there are direct SQL select statements and NO Web service existence across the custom applications. Data size is also not much high, few plugins and workflows defined in CRM system. Since long everything has worked but suddenly from last 2-3 months we have started seeing performance issues where end users are seeing slowness, or screen taking long time than expected to load controls, or Timeout errors.
This issue is not constant its an intermittent issue and it happens in business hours (PST/EST)
I wanted to know if there is any way to capture the logs about the issue in CRM, any, way in CRM where I can go and refer the log information or error traces which will help me to get the bottom of this issue?
I think the old tools/diagnostics/diag.aspx page should still work on-prem.
Just append that path to your Dynamics URL, e.g.: https://myOrg.mydomain.com/tools/diagnostics/diag.aspx
When you click Run it will generate some stats about the network and form performance.
Dynamics also has diagnostics tracing capabilities built in (or at least it used to - haven't tried recently.) This article has instructions on that.
Here's a summary (unconfirmed & untested)
On the CRM Server
Open registry (run regedit)
Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRM
Add new keys:
Name: TraceEnabled
Type: DWORD
Value: 1
Name: TraceDirectory
Type: String
Value: C:\CRMTrace
Name: TraceRefresh
Type: DWORD
Value: 99
Create the folder "CRMTrace" in C directory
Reset IIS (Run CMD as administrator >> execute this “iisreset” command )
This article has more, including PowerShell instructions.
Back in the day there was a desktop app called the Diagnostics Tool that allowed you to turn the logging on and off.
Also, please note that if you accidentally leave the logging on, it can fill up the C: drive and crash the server!
Using AWS' DocumentDB, I've deployed a test database cluster in Germany. When I run a test-query on it from an EC2 instance in Germany, it takes less than a 2 seconds. When I query it from my country (middle-east) it takes more then a minute.
This is the simple test I run (it just goes through the whole collection):
var last_doc= db.dev.find()
while(last_doc.hasNext()){ last_doc = last_doc.next(); }
Thing is, we also have an RDS (MySQL) DB in AWS and a query of the same size takes less than 2 seconds from my country to RDS (Also in Germany).
I tried viewing the logs so I followed this document but I can't seem to find any logs from docdb in CloudWatch. These are my cluster parameters. I also tried opening a ticket with AWS but apparently our basic subscription doesn't allow creating tickets.
Does anyone happen to have suggestion on how to tackle this? What should I do/look for?
Thanks ahead!
DESCRIPTION OF PROBLEM:
When syncing large items (such as images) with NSPersistentCloudKitContainer, my app crashes with the error 'NSAllocateMemoryPages() failed'. This happens repeatedly within a minute of launching the app. It happens both in production and development environments.
The crash does not happen if the user disconnects from the internet, or turns off iCloud sync for my app.
The images are stored in Core Data as "Binary Data" in separate entities with "many to one" relationships to their parent entities. The setup is adapted from this exaple: https://developer.apple.com/documentation/coredata/synchronizing_a_local_store_to_the_cloud
STEPS TO REPRODUCE:
Add multiple images to core data at once or sync with an iCloud account that already has multiple images in the private iCloud container.
PLATFORM AND VERSION:
Happens on both iPhone X and iPad Pro (gen 1) running iOS 13.3.1.
Have anybody else come accross this issue? All suggestions will be very welcome!
I found the problem in the end. I was storing full-res images of sizes exceeding 20 MB. Compressing the images made the problem go away. It looks like NSPersistentCloudKitContainer is not happy with syncing RawData fields larger than around 15 MB. If anyone has more details on this I would be very interested to learn more about this size-limitation and where/if it is documented!
I have multiple clients that use sqlbackupandftp. I was wondering a solution to monitor the backups of all clients. After some search, I found Magikmon. But this "service" is not working and nobody answers to my emails.
There's another solution for my problem?
If I want to develop something like this, what's the best way to do it (which program language)?
We are the developers of SQLBackupandFTP. In the program check "See backup history on the web" for all your clients and you will be able to see your clients' SQL backup results from a single "web log" page - more details in this blog post:
Alternatively you can use our other product SqlBak, where you can monitor backup results for multiple clients/databases and configure it all on the web as well:
Running WSo2 EMM 1.1.0, everything has been working just fine except for one big issue.
From the moment I first click on an app in the App Management tab, the WSO2EMM_DB.h2.db file starts to steadily grow as long as the server is running, even with absolutely no changes. Eventually, it gets so big that clicking an app on that tab takes a ridiculously long time to load the list of devices using the app. We're talking 5+ minutes, it becomes completely unusable. I have checked the error logs and found no errors at all, every time.
Restarting the server does nothing to correct the issue. Even if I click an app on the App Management tab once, and never again, the database file will continue to grow. Even restarting the server and not logging into the EMM page, it will continue to grow.
The only thing I've found so far that can possibly help is keeping backup copies of the database file and overwriting the current file when it gets too big. Obviously that's not a solution, as I'd need to create a new backup file every time there's a change on the server, and eventually the database file would grow too big from that too.
It's not an issue with the H2 database either. Not only have I tried starting over fresh several times and have had the same behavior, but here is the only info I could find regarding this issue, and they were having the issue regardless of whether or not it was on H2 or MySQL.
I've been trying to find a solution for this for over a month with no success. Any help would be appreciated!
EDIT: It looks like this might be the subject of EMM-826. Unfortunately there seems to be no response to that bug report so far.
EDIT 2: EMM-826 was closed with a message saying the following:
This issue is fixed in the EMM 1.1.0 GA latest pack. Please get all the patches for the product/build the product from the latest source [ https://github.com/wso2/product-emm ] and try again.
Unfortunately, that did not work for me. I'm not sure what exactly I'm doing wrong, so I'll list the what I did to try to fix it:
Downloaded the EMM 1.1.0 zip from http://wso2.com/products/enterprise-mobility-manager/.
Downloaded the zip from https://github.com/wso2/product-emm and pasted the files from that into my EMM_HOME directory.
When that didn't work, I searched for patches and found I was only using patches 1-6. In the documentation I found I could download patches 7-12 here. Patches 9 and 10 didn't work right for some reason; causing me not to be able to reach the EMM dashboard or publisher. I could only access the Carbon manager. I was able to make patches 7, 8, 11, and 12 work though - with no change in behavior.
Here are the steps I take to reproduce the issue:
After setting a fresh copy of the EMM up, I log in to the EMM dashboard as Admin, set up a user account, and upload an app through the Publisher.
Register a device to the user account I set up. In this case, an Android device running Android 4.2.2.
From the dashboard, I go to App Management and click the app I uploaded. The list of devices loads, but from that point on, the database file starts growing and eventually, after several hours, becomes so large it the device list will never load.
Please help!
Found this happening also, from a quick look it's the WSO2EMM_DB.notifications table. Seems to keep a history of all notifications over time, and the info for app installs is taken from non-optimized queries, which degrade as the table grows. You 'could' delete all rows from the table, and it will re-populate as devices 'check back' and report their info.
But you'd probably want to write a query to just keep the latest notification of each type of each user (I'll leave that to someone else...) and as was mentioned, it is apparently fixed in the latest version.
Issue appears to be resolved in EMM 2.0, which can be found here.