I have about 25000 failed writes within each 30 minutes. Previously I had an issue with timestamps ahead of current server clock, but this was addressed. When looking at collected data, it is OK - no gaps all values are good.
Is there any way I can tell why those writes fail?
Try checking the log files. For version 4.5 it should be in deafult path "C:\Proficy Historian Data\LogFiles"
Related
I have a rather complex workflow with 750 samples and roughly 18.000 jobs, at first snakemake runs just fine but then after around 4.000 jobs it suddenly freezes and upon restart it hangs with "Select jobs to execute..." for 24h, after that I terminated it. The initial DAG building takes roughly 2-3 minutes, though.
When I run snakemake (v5.32.0 and v5.32.1) with the --verbose option, I get tons of lines similar to this one:
Cbc0010I After 600 nodes, 304 on tree, -52534.791 best solution, best possible -52538.194 (7.08 seconds
I tried to delete the .snakemake folder in the hope that something went riot there, but that wasn't the case, unfortunately. To me it seems that the CBC MILP Solver somehow does not converge, and it keeps going and going to bring the best and the best possible solution closer together!?
Now I do not have any idea anymore, how to proceed and fix the problem. My possible solutions are somehow to change the convergence criteria or the solver itself. In the manual I found the option --scheduler-ilp-solver but it has apparently only one option, the default COIN_CMD.
After terminating a (shorter) run, I get this verbose output
Result - User ctrl-cuser ctrl-c
Objective value: 52534.79114334
Upper bound: 52538.202
Gap: -0.00
Enumerated nodes: 186926
Total iterations: 1807277
Time (CPU seconds): 1181.97
Time (Wallclock seconds): 1188.11
Next I will try to limit the number of samples in the workflow and see if this has any impact (for other datasets with 500 samples, it ran without any problems (with snakemake version 5.24), but there the DAG building took some hours. Hence, I am not very eager to try the old version.)
So, any idea how to fix the problem is highly appreciated. Also, I do not even know, if this is a bug!?
EDIT Actually, I believe it is a bug in the current version, I downgraded Snakemake back to version 5.24, it created the DAG within 10 minutes and started to run the pipeline. So, apparently there is some bug with the latest version. I will make this an answer to my own question, as the downgrading to an older version solved the problem...
I also ran into this issue with a smaller workflow (~1500 jobs total) and snakemake version 6.0.2. About half the jobs had run when the workflow got stuck, and refused to run any more jobs. Looks like it's a problem specific to the ILP solver, because when I re-ran with --scheduler greedy, it worked fine.
Actually, I believe it is a bug in the current snakemake version, I downgraded Snakemake back to version 5.24, it created the DAG within 10 minutes and started to run the pipeline. So, apparently there is some bug with the latest version. I will make this an answer to my own question, as the downgrading to an older version solved the problem...
We have this huge source-code base. We scan it using HP SCA and create a fpr file ( size app 620 MB). Then we upload it to our fortify server using "fortifyclient" command.
After uploading, if i log into the fortify server and go into details of that project, i see that the artifact is in "processing" stage. It remains in processing stage even after few days. There is no way provided on the dashboard using which i can stop /kill/delete it.
Ques 1: Why is it taking so long to process ( We have 1 successfully processed fpr report that took 6 days ). What can we do to make it faster?
Ques 2: If i want to delete a artifact while it in in processing stage, how to do that?
Machine Info:
6 CPUs (Intel(R) Xeon(R) 3.07GHz )
RAM 36 gig
Thanks,
Addition:
We had 1 report that was successfully processed earlier in the month for the same codebase. FPR file for that was of also of similar size (610 MB ) . I can see the issue count for that report. Here it is:
EDIT:
Fortify Version: Fortify Static Code Analyzer 6.02.0014
HP Fortify Software Security Center Version 4.02.0014
Total issues: 157000
Total issues Audited: 0.0%
Critical issues: 4306
High: 151200
Low: 1640
medium: 100
That's a large FPR file, so it will need time to process. SSC is basically unzipping a huge ZIP file (that's what an FPR file is) and then transferring the data into the database. Here are a few things to check:
Check the amount of memory allotted for SSC. You may need to pass up to 16Gb of memory as the Xmx value to handlean FPR that size. Maybe more. The easiest way to tell would be to upload the FPR and then watch the java process that your app server uses. See how long it takes to reach the maximum amount of memory.
Make sure the database is configured for performance. Having the database on a separate server with the data files on another hard drive can significantly speed of processing.
As a last resort, you could also try making the FPR smaller. You can turn off the source rendering so that source code is not bundled with the FPR file. You can do this with this command:
sourceanalyzer -b mybuild -disable-source-bundling
-fvdl-no-snippets -scan -f mySourcelessResults.fpr
As far as deleting an in progress upload, I think you have to let it finish. With some tuning, you should be able to get the processing time down.
Has anybody mentioned data errors, trigger error or upload errors in ChipScope?
I'm using ChipScope (from ISE 14.7) with the IP core flow. So I created 15 different ICON IP cores as ngc files and wrapped them all in a VHDL module. This module chooses by generic with ngc file should be instantiated. So I can easily choose the number of active VIO/ILA cores.
Currently my project has 2 VIO cores and 5 ILA cores, utilizing circa 190 BlockRAMs on a Kintex-7 325T (>400 BlockRAMs in total). When a trigger event occurs, I get sometimes the warning Did not find trigger mark in buffer. Data buffer may be corrupted. or Data upload error.
This error is independent of the trigger mode (normal trigger event, immediate trigger, startup trigger). It seams to happen mostly on Unit 4 (91 bit data * 32k depth + 3 trigger ports each of 4 units). The upload progress bar can stops at any percentage from 1 to 95% as far as I noticed.
Additionally I get hundreds of these warnings:
Xst - Edge .../TransLayer_ILA2_ControlBus<14> has no source ports and will not be translated to ABC.
My google research: ignore them :)
There is also a bug in XST: This warning has no ID and can't be filtered :(
As of now, I tried to fix this problem:
Reduced / Increased JTAG speed -> no effect (program device is not effected)
recompiled ip core / new ngc file
reduced ILA windows size
So what can it be?
P.S. All timings are met.
I found the problem and a solution.
The problem: I changed one ILA coregenerator file's name and it's contents (modified internal name with an editor). But I missed one parameter so CoreGen generated some sources under the old name. This was still in usage by another ILA core, so one of them got overwritten.
Solution:
I opened every ILA xco file and every cgp file and check all names.
In HBase before writing into memstore data will be first written into the WAL, but when i checked on my system
WAL files are not getting updated immediately after each Put operation, it's taking lot of time to update. Is there any parameter i need to set?
(WAL has been enabled)
Do you know how long it takes to update the WAL files? Are you sure the time is taken in write or by the time you check WAL, it is already moved to old logs. If WAL is enabled all the entries must come to WAL first and then written to particular region as cluster configured.
I know that WAL files are moved to .oldlogs fairly quickly i.e. 60 seconds as defined in hbase-site.xml through hbase.master.logcleaner.ttl setting.
In standalone mode writing into WAL is taking a lot of time, where as on pseudo distributed mode it's working fine
Is there a way to determine change frequency of a file?
The situation is i have a log file which will be rolling all the time, in that way i can say my application is running .
if it's not writing any then i can say there's some problem.
So instead of using tail and see manually if the logs are rolling , how can i check if the log is rolling programmatically like analysing it for 2 mins and checking if logs are being written?
Is there a way to track the change interval by using stat in some program kinda ???
i mean i can take 2 mins as parameter,at first storing mtime and after 2mins checking with new time and confirming it's changed, but i need to know the frequency kinda like x modifications/time or number.of.lines written/sec kinda
A better idea would be to have inotify, gamin, or FAM notify you when the file has been modified.
On a Unix system, the stat() family of functions will obtain a file's metadata. The st_mtime member of the struct stat structure will give you the time of last modification.
Also on a Unix system, sending a signal 0 to a process will tell you if the process is still alive without affecting the process.