March 2020 - users-list

[MonetDB-users] Proofreading your professional documents
by Richard Hounslow 24 Feb '24

24 Feb '24

Dear Professor/Lecturer Please excuse us for contacting you directly. We are offering an efficient service to help you ensure your academic and professional work is written in perfect English. We will check the grammar and style of your work and return it to you to meet your requirements and deadlines. Proof-Reading-Service.com can provide you with a professional proofreading service at a very reasonable rate. All our proofreaders are highly qualified native English speakers. Many work as leading academics in their fields and all have extensive experience of proofreading to the highest standards. If you are interested in our service, please take a look at our website: www.proof-reading-service.com All you have to do is send us your document as a word attachment with the deadline and we will guarantee delivery of a perfectly written document to give you complete confidence when you submit your work. The fee is worked out on a flat rate (£6.95 per thousand words or 0.695 pence per word), so you know exactly how much the proofreading will cost in advance. Once we have received your document(s) we will confirm the word count, the price and the deadline. If you have not heard from us within 2 hours during normal business hours after you have sent your work please resend it from a different email account or send the file to proofreadings(a)gmail.com. We look forward to hearing from you! Yours faithfully Proof-Reading-Service.com

2 2

Compilation error macOS Catalina
by Ying Zhang 16 Apr '20

16 Apr '20

Hai all, Compiling MonetDB Mercurial source on macOS Catalina (10.15.4) results in the following error: /Users/jennie/monet/Nov2019/common/utils/mcrypt.c:476:3: error: 'CC_MD5_Final' is deprecated: first deprecated in macOS 10.15 - This function is cryptographically broken and should not be used in security contexts. Clients should migrate to SHA256 (or stronger). [-Werror,-Wdeprecated-declarations] MD5_Final(md, &c); ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/CommonCrypto/CommonDigest.h:282:37: note: expanded from macro 'MD5_Final' #define MD5_Final CC_MD5_Final ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/CommonCrypto/CommonDigest.h:139:12: note: 'CC_MD5_Final' has been explicitly marked deprecated here extern int CC_MD5_Final(unsigned char *md, CC_MD5_CTX *c) ^ 7 errors generated. How can I get rid of this error? Disable -Wdeprecated-declarations? Or disable MD5 but use SHA256 instead? Thanks! Jennie

2 1

Fwd: BULK UPLOAD very poor performance
by Ariel Abadi 01 Apr '20

01 Apr '20

Hi! After a big battle against the DB, I found 2 issues. 1) Running the COPY RECORDS FROM *STDIN *and from *FILE*. Is totally different in terms of performance. While the first one last 24 minutes, the second one last only *90 secs.* 2) As I had generated all those files thru msqldump (which it states the "CREATE TABLE" instruction and then the COPY RECORDS)... I try ro run the COPY *XXXX OFFSET *RECORDS (in order to avoid the create table statement)... and the query, because of the word "STDIN" in the file. It was not OFFSETTING all the rows I was asking for. I hope I've been clear... if not please let me know! Ariel On Tue, Mar 24, 2020 at 11:33 PM Martin Kersten <martin.kersten(a)cwi.nl> wrote: > Hi > > I am not sure what issue you are now dealing with, but since you are a > company > that seems to use (or considering) MonetDB in your commercial offerings, > I gladly refer you to MonetDBSolutions(*), where we can give you the > commercial > support needed to diagnose your issues. > > regards Martin > > (*) https://www.monetdbsolutions.com/ > > On 24/03/2020 23:55, Ariel Abadi wrote: > > Thanks Martin for your prompt response > > But I did and msqldump from other database, and now the upload is being > done thru the BULK LOAD. > > > > /COPY 14173375 RECORDS INTO "sb_traf"."nrm_20180818" FROM stdin USING > DELIMITERS '\t','\n','"';/ > > > > > > Any other idea ? :'( > > > > > > > > > > On Tue, Mar 24, 2020 at 7:37 PM Martin Kersten <martin.kersten(a)cwi.nl > <mailto:martin.kersten@cwi.nl>> wrote: > > > > Hi, > > > > given the numbers I suspect you are loading them as SQL insert > statements under autocommit mode, > > Please read the documentation on Bulk loading. > > > > regards,Martin > > Sent from my iPad > > > >> On 24 Mar 2020, at 23:12, Ariel Abadi <aabadi(a)starbi.com <mailto: > aabadi(a)starbi.com>> wrote: > >> > >> > >> Hi! > >> Maybe somebody can help me, please! > >> > >> I'm trying to upload into Monet a file with 14MM records. Is taking > more than *24 minutes.* > >> It is a fresh new database. > >> > >> Enclosed you will find the server configuration. > >> > >> Monetdb Version Nov2019-SP3 > >> > >> > >> *[root@mn tmp]$ lscpu* > >> Architecture: x86_64 > >> CPU op-mode(s): 32-bit, 64-bit > >> Byte Order: Little Endian > >> CPU(s): 40 > >> On-line CPU(s) list: 0-39 > >> Thread(s) per core: 2 > >> Core(s) per socket: 10 > >> Socket(s): 2 > >> NUMA node(s): 2 > >> Vendor ID: GenuineIntel > >> CPU family: 6 > >> Model: 85 > >> Model name: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz > >> Stepping: 4 > >> CPU MHz: 800.479 > >> BogoMIPS: 4400.00 > >> Virtualization: VT-x > >> L1d cache: 32K > >> L1i cache: 32K > >> L2 cache: 1024K > >> L3 cache: 14080K > >> NUMA node0 CPU(s): > 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 > >> NUMA node1 CPU(s): > 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39 > >> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep > mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts > rep_good nopl xtopology nonstop_tsc > >> cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est > tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe > popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm > 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 > >> invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow > vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep > bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap > clflushopt clwb intel_pt avx512cd avx512bw > >> avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc > cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke md_clear > flush_l1d > >> > >> > >> *[root@mn tmp]$ cat /proc/meminfo* > >> > >> MemTotal: 83886080 kB > >> MemFree: 10535812 kB > >> MemAvailable: 80159744 kB > >> Buffers: 0 kB > >> Cached: 69623932 kB > >> SwapCached: 0 kB > >> Active: 6625436 kB > >> Inactive: 63737872 kB > >> Active(anon): 324456 kB > >> Inactive(anon): 417184 kB > >> Active(file): 6300980 kB > >> Inactive(file): 63320688 kB > >> Unevictable: 0 kB > >> Mlocked: 5320 kB > >> SwapTotal: 8388604 kB > >> SwapFree: 8381988 kB > >> Dirty: 220 kB > >> Writeback: 0 kB > >> AnonPages: 13626052 kB > >> Mapped: 186368 kB > >> Shmem: 1800 kB > >> KReclaimable: 4134960 kB > >> Slab: 0 kB > >> SReclaimable: 0 kB > >> SUnreclaim: 0 kB > >> KernelStack: 16720 kB > >> PageTables: 56500 kB > >> NFS_Unstable: 0 kB > >> Bounce: 0 kB > >> WritebackTmp: 0 kB > >> CommitLimit: 74123472 kB > >> Committed_AS: 18337812 kB > >> VmallocTotal: 34359738367 kB > >> VmallocUsed: 415836 kB > >> VmallocChunk: 0 kB > >> Percpu: 39552 kB > >> HardwareCorrupted: 0 kB > >> AnonHugePages: 0 kB > >> ShmemHugePages: 0 kB > >> ShmemPmdMapped: 0 kB > >> CmaTotal: 0 kB > >> CmaFree: 0 kB > >> HugePages_Total: 0 > >> HugePages_Free: 0 > >> HugePages_Rsvd: 0 > >> HugePages_Surp: 0 > >> Hugepagesize: 2048 kB > >> Hugetlb: 0 kB > >> DirectMap4k: 816396 kB > >> DirectMap2M: 82513920 kB > >> DirectMap1G: 52428800 kB > >> > >> > >> > >> > >> _______________________________________________ > >> users-list mailing list > >> users-list(a)monetdb.org <mailto:users-list@monetdb.org> > >> https://www.monetdb.org/mailman/listinfo/users-list > > _______________________________________________ > > users-list mailing list > > users-list(a)monetdb.org <mailto:users-list@monetdb.org> > > https://www.monetdb.org/mailman/listinfo/users-list > > > > > > _______________________________________________ > > users-list mailing list > > users-list(a)monetdb.org > > https://www.monetdb.org/mailman/listinfo/users-list > > >

5 11

BULK UPLOAD very poor performance
by Ariel Abadi 24 Mar '20

24 Mar '20

Hi! Maybe somebody can help me, please! I'm trying to upload into Monet a file with 14MM records. Is taking more than *24 minutes.* It is a fresh new database. Enclosed you will find the server configuration. Monetdb Version Nov2019-SP3 *[root@mn tmp]$ lscpu* Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 40 On-line CPU(s) list: 0-39 Thread(s) per core: 2 Core(s) per socket: 10 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz Stepping: 4 CPU MHz: 800.479 BogoMIPS: 4400.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 14080K NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke md_clear flush_l1d *[root@mn tmp]$ cat /proc/meminfo* MemTotal: 83886080 kB MemFree: 10535812 kB MemAvailable: 80159744 kB Buffers: 0 kB Cached: 69623932 kB SwapCached: 0 kB Active: 6625436 kB Inactive: 63737872 kB Active(anon): 324456 kB Inactive(anon): 417184 kB Active(file): 6300980 kB Inactive(file): 63320688 kB Unevictable: 0 kB Mlocked: 5320 kB SwapTotal: 8388604 kB SwapFree: 8381988 kB Dirty: 220 kB Writeback: 0 kB AnonPages: 13626052 kB Mapped: 186368 kB Shmem: 1800 kB KReclaimable: 4134960 kB Slab: 0 kB SReclaimable: 0 kB SUnreclaim: 0 kB KernelStack: 16720 kB PageTables: 56500 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 74123472 kB Committed_AS: 18337812 kB VmallocTotal: 34359738367 kB VmallocUsed: 415836 kB VmallocChunk: 0 kB Percpu: 39552 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB CmaTotal: 0 kB CmaFree: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 816396 kB DirectMap2M: 82513920 kB DirectMap1G: 52428800 kB

2 2

Slowdown behaviour after loading large amounts of data
by stephenb 23 Mar '20

23 Mar '20

We believe we might be observing the behaviour described here: https://www.monetdb.org/blog/monetdb-sql-transaction-management-scheme Specifically “At certain intervals, if the database is idle, the store manager will merge the updates from the WAL into the primary storage” We perform some heavy updates to the database (we have experimented with putting these in a single transaction or having separate transactions for each, but the behaviour is the same). The updates are basically dropping tables, recreating them and then a COPY INTO. Once the final load has finished, and has been committed, for around 30 seconds we can query the database, but then for a period of several minutes it basically locks up. I wonder if there is any way to control this behaviour? Regards Steve

1 0

stethoscope tool
by Suresh Devarakonda 12 Mar '20

12 Mar '20

Thank you Sjoerd Mullender. I am able to install it. ====== Doing sudo yum install /usr/bin/stethoscope should do it. That will install the package MonetDB-client-tools. On 09/03/2020 16.11, Suresh Devarakonda wrote: > Hi, > > > > I would like to use the stethoscope tool to monitor the performance of > queries. But, I do not find the tool in the MonetDB software that I > installed on my server. Can you help me to get the stethoscope tool. > > > > [root at xxxxxx<https://www.monetdb.org/mailman/listinfo/users-list> ~]# yum list installed |grep -i monet > > MonetDB.x86_64 11.35.9-20191218.el7 @monetdb > > MonetDB-SQL-server5.x86_64 11.35.9-20191218.el7 @monetdb > > MonetDB-client.x86_64 11.35.9-20191218.el7 @monetdb > > MonetDB-client-odbc.x86_64 11.35.9-20191218.el7 @monetdb > > MonetDB-release-epel.noarch 1.3-1.monetdb installed > > MonetDB-stream.x86_64 11.35.9-20191218.el7 @monetdb > > MonetDB5-server.x86_64 11.35.9-20191218.el7 @monetdb > > > > > > > > *Suresh Devarakonda* > > *84.51* <http://www.8451.com/>*° * > > *TDO - Database Support Team* > > *D:*513.632.3692 > > *M*: 859.512.1839 > > *A: *100 W. 5^th Street, Cincinnati, Ohio 45202 > > > > Cincinnati *|* Chicago *|* New York *|* Portland > > Facebook > <https://www.facebook.com/8451group/?ref=aymt_homepage_panel> LinkedIn > <https://www.linkedin.com/company/84-51/?trk=biz-companies-cym> Instagram > <https://www.instagram.com/84.51/> Twitter > <https://twitter.com/8451group> > > Please consider the environment before printing this email. > > > > > > > _______________________________________________ > users-list mailing list > users-list at monetdb.org<https://www.monetdb.org/mailman/listinfo/users-list> > https://www.monetdb.org/mailman/listinfo/users-list > ________________________________ * Previous message (by thread): stethoscope tool<https://www.monetdb.org/pipermail/users-list/2020-March/010593.html> * Messages sorted by: [ date ]<https://www.monetdb.org/pipermail/users-list/2020-March/date.html#10594> [ thread ]<https://www.monetdb.org/pipermail/users-list/2020-March/thread.html#10594> [ subject ]<https://www.monetdb.org/pipermail/users-list/2020-March/subject.html#10594> [ author ]<https://www.monetdb.org/pipermail/users-list/2020-March/author.html#10594>

1 0

stethoscope tool
by Suresh Devarakonda 09 Mar '20

09 Mar '20

Hi, I would like to use the stethoscope tool to monitor the performance of queries. But, I do not find the tool in the MonetDB software that I installed on my server. Can you help me to get the stethoscope tool. [root@xxxxxx ~]# yum list installed |grep -i monet MonetDB.x86_64 11.35.9-20191218.el7 @monetdb MonetDB-SQL-server5.x86_64 11.35.9-20191218.el7 @monetdb MonetDB-client.x86_64 11.35.9-20191218.el7 @monetdb MonetDB-client-odbc.x86_64 11.35.9-20191218.el7 @monetdb MonetDB-release-epel.noarch 1.3-1.monetdb installed MonetDB-stream.x86_64 11.35.9-20191218.el7 @monetdb MonetDB5-server.x86_64 11.35.9-20191218.el7 @monetdb [cid:image001.jpg@01D5F602.57C58E70] Suresh Devarakonda 84.51<http://www.8451.com/>° TDO - Database Support Team D: 513.632.3692 M: 859.512.1839 A: 100 W. 5th Street, Cincinnati, Ohio 45202 Cincinnati | Chicago | New York | Portland Facebook<https://www.facebook.com/8451group/?ref=aymt_homepage_panel> LinkedIn<https://www.linkedin.com/company/84-51/?trk=biz-companies-cym> Instagram<https://www.instagram.com/84.51/> Twitter<https://twitter.com/8451group> Please consider the environment before printing this email.

2 1