we have datastage jobs on production that recently stop showing performance statistics. We already made sure that we have enough memory for the logs and we didn't see any errors in jobmon.log and tried restarting it a couple of times. APT_JOB_MON is set to false. And localhost is set at etc/host. Asking for any idea what could be the problem.
Assuming you mean the statistics on the link in the Datastage Designer - if nothing at all is shown make sure the statistics are switched on in the GUI (there is a button for that or a menu entry)
Also check this help document for job monitor problems by IBM
Related
I have a 9Mb PBIX containing small tables and one table with 250k rows. Data imported from various xlsx & JSON sources. Machine is Windows 10 Pro, 2.6GHz, 64 bit, 16GB RAM.
On the Power BI service online the performance is ok, but on desktop it's practically unworkable. With task manager I can see that it is using 7Mb of memory, but almost 100% CPU, half an hour after opening - while on a blank tab with no visualisations.
I don't understand what it is doing in the background and how I can improve the situation.
There is the 'Allow data preview to download in the background' setting, but I think this is only relevant to the query editor? Would clearing the cache or changing cache settings help?
I am aware of performance analyzer and the query diagnostics tools, but neither seem relevant since the queries are not refreshing and there are no visualisations loading.
Am at a bit of a loss - any help greatly appreciated.
Thanks
Update: Having disabled parallel load and background refresh in Data load settings I noticed that finally the issue seemed to go away (though not immediately). Eventually, when reopening the pbix, mashup containers did not appear and CPU and memory was not being killed. Then at some point Power BI got stuck and had to close and the problem reappeared even though the data load settings were still disabled. Restarting the machine seemed to clear the problem once again.
It seems then, that some zombie processes can persist through application close and re-open. Has anyone else noticed this, can confirm or refute it, suggest what is going on or any steps on how to avoid/prevent? It's very annoying!
Thanks
I have also noticed the same issue, for opening 5 mb pbix file, power bi eating 12 GB of memory, and 90%+ CPU utilization, Power BI Desktop is poorly managed product by Microsoft.
I tried to sync database on Visual Studio 2015 after creating a project, EDT, Enum and a Table in order to create a new screen on Dynamics 365.
When I tried to synchronize it, it was stopped in the middle during schema checking process. Though it seems that the DB synchronization doesn't have problem for the first few minutes, it always stops during this process as I describe below.
Log Details:
"Schema has not changed between new table 'DPT_TableDT' and old table
'DPT_TableDT' with table id '3997'. Returning from
ManagedSyncTableWorker.ExecuteModifyTable() Syncing Table Finished:
DPT_TableDT. Time elapsed: 0:00:00:00.0010010"
Could you tell me how to solve this issue?
Thanks in advance.
Full database synchronization log
DB Sync Log
From what you've described and also shown in your screenshot, this does not look like an error but is simply describing X++ and Dynamics AX/365FO behaviour.
When you say that it "doesn't have a problem for the first few minutes" I'm guessing you're just not being patient enough. Full database syncs should generally take between 10-30 minutes, but can take shorter or longer depending on a variety of factors such as how much horsepower your development environment has, how many changes are being sync'd etc. I would wait at least one hour before considering the possibility that the sync engine has errors (or even run it overnight and see what information it has for you in the morning).
The message you've posted from the log ("Schema has not changed") isn't an error message; it is just an informational log from the sync engine. It is simply letting you know that the table did not have any changes to propagate to SQL Server.
Solution: Run the sync overnight and post a screenshot of the results or the error list window in Visual Studio.
I've recently been stymied by a long running application where Access v2003 replicas refused to synchronize. The message returned was "not enough memory". This was on machines running Windows 10. The only way I was able to force synchronizing was to move the replicas onto an old machine still running Windows 98 with Office XP, which allowed synchronizing and conflict resolution. When I moved the synchronized files back to the Windows 10 machine they still would not synchronize.
I finally had to create a blank database and link to a replica, then use make-table queries to select only data fields to create new tables. I was then able to create new replicas that would synchronize.
From this I've come to suspect the following:
Something in Windows 10 has changed and caused the problem with synchronizing/conflict resolution.
Something in the hidden/protected fields added to the replica sets is seen as a problem under Windows 10 that is not a problem under Windows 98.
One thing I noticed is that over the years the number of replicas in the synchronizing list had grown to over 900 sets, but the only way to clear the table was to create a new clean database.
I have an MVC3 C#.Net web app. It is running on IIS 7 on Windows Server 2008 R2. We are noticing significant performance issues when initially loading a page. We are using nHibernate and have found that performance to be slow in some instances. But all pages, even simple ones, behavinging similarly. I'm not really an IIS stud so.....
Am I missing something in IIS....a setting or action that I can tweak to improve performnce?
I had a similar issue running a site on a shared host that only allocated 100MB RAM to an application pool. When you exceeded that IIS was set to recycle it. The app generally ran at about 120MB so was constantly recycling. Each page was loading painfully slow as the whole thing started up again. Increasing the RAM available to the app pool fixed it.
Another thing that I'd try would be to set up SQL profiler and watch the queries being sent to the db. You can configure it to report the duration column in a smaller increment than the default (microseconds perhaps?) which makes the painful ones stand out. You can then pick up ones that are suspect, run them through query analyser with "display execution plan" switched on and examine the subtree costs. Perhaps NHibernate is generating nasty queries or perhaps too many?
I wrote a similar question before but I got no answers so I was thinking on asking again in a simpler way.
I have slony-I replicating databases in a windows environment (Master has windows xp and slave has windows 7, both with postgreSQL 8.2). I registered a service using slon -regservice in both master and slave and everything works fine.
The problem I have is that the service is writing logs in the event viewer every time it runs so I have 5 or 6 new logs every second. I was hoping that it would write only errors in the event viewer but it writes logs all the time and the event viewer in my master server is getting filled with them. Since windows xp has a limit of space in the event viewer, the logs make the event viewer reach its limit and all the applications that use the event viewer crash.
Is there a way to configure the slony service to avoid writing logs in the event viewer?
Any help will be greatly appreciated. I've been struggling with this problem for 2 weeks now and I read every tutorial in the web and all of them have the same instructions but none of them mentions the logs in the event viewer. Am I missing something?
Thanks!
You probably ought to raise a bug in the Slony-I bug database or e-mail their mailing list. Since it is open source you could even re-build it and remove the unwanted event logging. Also, you don't need to register to receive event logs but you probably want errors.
You appear to be using Windows XP which is rather decrepit now – it's 10 years old! The modern versions of Windows have much more resilient event logs.
Finally, you could reconfigure the event log settings to try to avoid the problem. You could make the log much bigger (512KB default is quite small) and there appear to be other settings available. Open the event viewer, right click one of the event logs and select properties.
An application is hanging occasionally, and I would like to see the dump at the time to figure it out. I had written an application that the user can run to automatically create a dump that I can look at. However I can't seem to get the users to remember to run it when it hangs, no matter what I try. They always end up closing the program, which invokes Windows Error Reporting.
WER will create dumps in the temp directory, but unfortunately they are deleted as soon as the dialog for sending the info to Microsoft or not is closed.
Becoming an ISV and getting this info from Microsoft's error reporting servers is one solution.. but not one that is realistic at the moment.
I can't imagine that I am the only one faced with this issue. The software is used concurrently by dozens upon dozens of staff, so reaching them all and getting them to run an application or not click close on that dialog until running some other application or etc has not been working out.
The app is running on Windows Server 2003. Too bad, since I know Server 2008 has some LocalDumps options that will let me retain them.
Any ideas for somehow keeping these dumps around so I can analyze them? The obstacle is the user, in the sense that I've accepted to their stubbornness and do not expect them to run any other application or do anything special.
Thanks for any advice!
You could opt for an automatic solution. I believe there're multiple options at your disposal for detecting if you're hung.
One would be the use of SendMessageTimeout (also pay attention to SMTO_ABORTIFHUNG as one of the fuFlags values) from a separate thread in your app. Once you have determined the main thread is not responding you can save a dump file wherever you want.
There's also a IsHungAppWindow() (user32.dll) available since w2k.