New post
AllAccepted answers
Alexey Maslov · Apr 18, 2019

You'd hardly find plugin for Caché for any 3d party tool, while SNMP support included in all InterSystems products allows easy integration with most of them (Zabbix, Nagios, etc). It's even possible to write custom MIB to provide additional metrics, we tried it and it really worked.

Nowadays more lightweight approaches are getting popular, such as Grafana based ones mentioned by Evgeny. I'd personally recommend to use enterprise scale tool such as Zabbix if and only if you really need a solution to monitor all parts of your data center infrastructure (servers, OS, LAN, etc) besides DBMS; otherwise it would look like overkill, I'd prefer Grafana based one.

Alexey Maslov · Apr 5, 2019

Both methods of calculation give the similar results in fast mode, while the %Library.GlobalEdit's one seems to be faster. The results of sizing of rather big global are:

< restart Caché >

USER>set t0=$zh
USER>set sc=##class(%Library.GlobalEdit).GetGlobalSize($zu(12,""),"zzz",.a,.u,1)
USER>zwrite sc,a,u write $zh-t0
sc=1
a=135819
22.542591

< restart Caché >

USER>set t0=$zh
USER>set as=$$AllocatedSize^%GSIZE("^zzz")/1024\1024
USER>zwrite as w $zh-t0
as=135818
28.29038

I withdrawing the comparison result as my testing environment was not stable (~ %30 "natural" fluctuations due to cloud hosting specific). Planning to repeat the test after getting more stable environment with such a large global(s).

Alexey Maslov · Mar 16, 2019

It can be a sign of too long Write Daemon buffer queues on your DR Backup member. The reason for it can be insufficient throughput of its disk i/o subsystem and/or problems with disk i/o. I should start with looking through cconsole.log for messages indicating:

  • abnormal latency of disk access
  • Write Daemon non-responsive "more than 5 minutes" states
  • Write Daemon panic
  • and so on.

Next step would be start pButtons monitoring around the clock to indicate the guessed issue(s) more selectively. Looking at OS performance logs can be helpful as well.

Alexey Maslov · Mar 15, 2019

Not touching "dot syntax" and argumentless "quit" in for what are the cases of using "quit" we have?

As to docs, "RETURN and QUIT differ when issued from within a FOR, DO WHILE, or WHILE flow-of-control structure, or a TRY or CATCH block." Besides these special cases, both commands work quite similar.

I didn't want to start discussing "RETURN vs QUIT", but if you insist... 

RETURN Pros:

  • visually clear sign of return from method/$$-function/do-subroutine call,
  • syntactically the same commands exist in many other programming languages,
  • due to ability to exit from any context without restrictions, RETURN can be accepted as a powerful feature for "alarm exit" on error.

RETURN Cons:

  • As to "alarm exit": QUIT combined with outer try / catch block does the same job (and even can do more of it).
  • It came too late; adding a new feature to the language which was kept unchanged for ages should have stronger reasons than it has (IMHO).
  • While substitution of QUITs with RETURNs in all appropriate places is not an easy task, the project code base may get a mixture of legal (and "legacy") QUITs and newer RETURNs, introduced by newcomers from other languages. I doubt if it would improve readability. BTW, to my surprise, I noticed RETURNs in one junior's class method, and never met it in middles' or seniors' code.
  • It can be important for some companies to support backward compatibility of their products with older and/or other versions of database management systems they use because it's not always possible to upgrade the customers to modern Caché / IRIS versions.
  • (funny one) Lazy developer has no option to use single-character shortcut for RETURN command. Three character word for one command is too long... wink
Alexey Maslov · Mar 14, 2019

Is that supposed to be hard? I immediately visually determined the result 20

Vitaliy, you are apparently not a beginner.

the t3 method code is equivalent to the following code

No, because my version can return a non-empty value having been called as a function, while yours can't.

absolutely nothing will change fundamentally if you replace "return" with "quit"

Absolutely agree, and that was my initial point already published in recent discussion:

  • If "QUIT" was used correctly, and one replaced it with "RETURN", no miracle will happen with code readability.
  • In contrast, forgetting or being unaware of possible side effects can make code understanding harder.

The sample was inspired by those thoughts. Its initial version was a bit more tricky, but InterSystems discourage an "old syntax" even to be used in discussions, while IMHO even a beginner should be aware of it and its caveats.

As to RETURN, it seems that InterSystems promotes this command nowadays as more visually clear remedy to exit methods. Before its addition to Caché docs mentioned "Implicit QUIT", and now it tell us about "Implicit RETURN", while "Implicit QUIT" is still around. 

Alexey Maslov · Mar 13, 2019

Evgeny,

Thank you for teaching me COS :)

Just a small note to finish it:

  • The rewritten sample is not functional equivalent of the original one and will return the different result (if correct the syntax error).
  • My sample was not about "old" syntax vs. "new" one; I just wanted to emphasize that simple substitute "quit" with "return" command either may or may not improve the readability of already existing class/routine, it all depends...
Alexey Maslov · Mar 12, 2019

Evgeny, agree with you, there is the difference, while I'm not sure what percent of community members will give the right answer to the question below without looking into docs and running the code. AFAIK, voting is impossible here.

What result will be returned by the method:

ClassMethod t1()
 {
  do t2(.a,.b)
  do
  . set a=4,b=5
  . return $increment(a)*$increment(b)
  return $increment(a,-1)*$increment(b,-1)
t2(&pA,&pB) ;
  set pA=2,pB=3
  return pA*pB
 }
Alexey Maslov · Mar 12, 2019

No, because as those

 quit sc

ever worked, they were used according to the rule cited above:

outside of a block structure or from within an IF, ELSEIF, or ELSE code block.

This is very personal, but I would never use RETURN, because it introduces backward incompatibility with older Caché versions without any real reason for it but using yet another "me too" "modern" feature. Besides, it provokes the developer to bypass modular approach rule that insists on having one and only one enter as well as exit from each functional module. Isn't it about real (rather than "me too") readability?

Again, that's only IMO, while I doubt if it's possible to issue any community accepted rule set for COS programming style.

Alexey Maslov · Feb 13, 2019

Continuing Robert's list:

5) CACHETEMP is always local on APP servers (= ECP clients). As to our experience, it's very important feature, because it allows to keep processing of temporary data locally, without extra network and ECP server disk i/o workload. One of surprises of ECP I've got:  while it's relatively easy to achieve high speed of intra-ECP networking (as far as ~10Gbit/s hardware is available), ECP server disk i/o subsystem can easily become a bottleneck unless you accurately spread data processing among ECP clients.

6) Sergio, you wrote:

I mean, all the data would be stored on disk and will have to be synchronized through the net with the other APP servers.

If you really need to synchronize even temporary data, then simple horizontal scaling with ECP without some optimization of data processing  (see p.5) can be less cost-effective than comparable vertical scaling solution.

Alexey Maslov · Feb 6, 2019

This is well-known classic approach how asynchronous behavior can be simulated in "synchronous only" language. It potentially suffers of two problems caused by the need to check if something has dropped to TCP connection:

1) Read x:timeOut (where timeOut>0) causes delays up to timeOut seconds which are more or less acceptable for background job but not acceptable for foreground (e.g., some UI handling).

2) Read x:0 is too unreliable.

Agree with Dmitry: it helps that "not all those tasks have to be asynchronous".

Alexey Maslov · Jan 9, 2019

Andrey, Evgeny:

while it was 3d party research, there are some signs of Caché performance tuning: global cache and routine cache were manually enlarged, journaling was switched off at the process level. Were the similar tuning steps performed for other DBMSs used in the research? 

  • AFAIK, Oracle would not allow to stop transaction logging (=journaling) at all. 
  • Only few people have appropriate knowledge of all DBMS products listed in the article (maybe Andrey is one of them), and nobody would touch hidden or semi-hidden performance parameters without it.

That's why I doubt if an Oracle engineer (or even DBA) would approve such "derby" results. 

Shouldn't we agree with an author of the sentence? :

...a single view of Oracle has lead to vastly different results, like the difference between a circle and a square. Always remember that there is no substitute for a real-world test that simulates the actual behavior of your production systems, using your own production SQL  (http://www.dba-oracle.com/t_benchmark_testing.htm)

Alexey Maslov · Dec 28, 2018

As you know for sure, pattern can be assign to variable:

 set list=$lb("abc", "c", "aaa", "bbb")
 set result = $$patmatch(list, "1(1(1.""a"".E),1(.E1.""b""))")
 ;set result = ..match(list, "a*,*b")
 zw result // result=$lb("abc","aaa","bbb")
 q

patmatch(pList, pPat)
 new result,i set result=""
 for i=1:1:$ll(pList) if $lg(pList,i)?@pPat set result=result_$lb($lg(pList,i))
 quit result
Alexey Maslov · Dec 5, 2018

A customer of ours is running a production system of two mirrored DB servers and 13 APP ones, running 24x7 with possible downtime <= 2 hours once a month.

Summary production DB size is ~ 4TB. Full backup takes ~ 10 hours, its restore ~ 16 hours. Therefore incremental backups are scheduled nightly, and full backup - weekly; to avoid performance drawback, Mirror Backup server is assigned to run all this activity.

As to integrity check, it turned to be useless since the DB size had overgrown 2TB: weekend had become not enough to run it through, so it was disabled. It doesn't seem to be a great problem because:

  • Enterprise grade SANs are very reliable, the probability of errors is very low.
  • Let's imagine that integrity error occurred. Which database blocks would be most probably involved? Those that are active changed by users' processes, rather than those that reside in "stale" part of the database. So, the errors would most likely appear on application level sooner than they might be caught with Integrity Check. What, do you think, would the administrator do in case of such kind of errors? Stop production for several days, running Integrity Check and fixing the errors? No, they would just switch from damaged Primary to (healthy) Backup Server. And what if Backup Server is damaged as well? As they reside on separated disk groups, this scenario means real disaster with the best solution: to switch to Async Backup which resides at another data center.