Menu
▾
▴
firebird-devel
|
From: Omacht A. <ao...@mv...> - 2018-01-09 09:53:10
|
Hi! Just for the shake of information. Our test system running on Debian 9.3. processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5420 @ 2.50GHz stepping : 6 microcode : 0x60b cpu MHz : 2500.117 cache size : 6144 KB ... We've done some test runs with the 'old' kernel (linux-image-4.9.0-4-amd64) and the 'new' one (linux-image-4.9.0-5-amd64). No. of tests: 6014 No. of result checks: 253555 (checking column values, stored procedure results, etc.) Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) The database file and the tmp directory located on ramdisk. András __________ Information from ESET Mail Security, version of virus signature database 16706 (20180109) __________ The message was checked by ESET Mail Security. http://www.eset.com |
|
From: Paul R. <pr...@ib...> - 2018-01-09 10:24:29
|
On Tue, 9 Jan 2018 09:52:59 +0000 Omacht András wrote > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) > Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) That is a massive hit. Has anyone had a chance to run tests on AMD kit? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird |
|
From: Sergey M. <se...@dq...> - 2018-01-09 10:56:42
|
Hi! Just for your information - if this is your own dedicated server and you do NOT run untrusted code on it (which can potentially steal your data and send to someone) - you can safely disable this patch. Just because you do not defend yourself from yourself :) Both vulnerabilities are LOCAL :) -- Best regards, Sergey mailto:se...@dq... On Tue, Jan 9, 2018 at 11:52 AM, Omacht András <ao...@mv...> wrote: > Hi! > > > > Just for the shake of information. > > > > Our test system running on Debian 9.3. > > processor : 7 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Xeon(R) CPU E5420 @ 2.50GHz > stepping : 6 > microcode : 0x60b > cpu MHz : 2500.117 > cache size : 6144 KB > … > > > > We’ve done some test runs with the ’old’ kernel > (linux-image-4.9.0-4-amd64) and the ’new’ one (linux-image-4.9.0-5-amd64). > > > > No. of tests: 6014 > > No. of result checks: 253555 (checking column values, stored procedure > results, etc.) > > > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) > > Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) > > > > The database file and the tmp directory located on ramdisk. > > > > András > > > __________ Information from ESET Mail Security, version of virus signature > database 16706 (20180109) __________ > > The message was checked by ESET Mail Security. > http://www.eset.com > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > > |
|
From: Paul R. <pr...@ib...> - 2018-01-09 11:11:44
|
On Tue, 9 Jan 2018 12:25:24 +0200 Sergey Mereutsa wrote > > Both vulnerabilities are LOCAL :) > Your server also has to be air-gapped from the internet and all its clients must also be air-gapped from the internet. If there is any connection to the outside world then all bets are off as one flaw can used to exploit another. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird |
|
From: Omacht A. <ao...@mv...> - 2018-01-09 11:14:57
|
Hi Sergey! Yes, I know, we can switch off the patch(es) on our servers, but fortunately we have customers and we have to answer their questions if they have. 😉 These tests covering the business logic, which is a good starting point for what customers expect when installing the patches. András From: Sergey Mereutsa [mailto:se...@dq...] Sent: Tuesday, January 9, 2018 11:25 AM To: For discussion among Firebird Developers <fir...@li...> Subject: Re: [Firebird-devel] Meltdown and Spectre Hi! Just for your information - if this is your own dedicated server and you do NOT run untrusted code on it (which can potentially steal your data and send to someone) - you can safely disable this patch. Just because you do not defend yourself from yourself :) Both vulnerabilities are LOCAL :) -- Best regards, Sergey mailto:se...@dq...<mailto:se...@dq...> On Tue, Jan 9, 2018 at 11:52 AM, Omacht András <ao...@mv...<mailto:ao...@mv...>> wrote: Hi! Just for the shake of information. Our test system running on Debian 9.3. processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5420 @ 2.50GHz stepping : 6 microcode : 0x60b cpu MHz : 2500.117 cache size : 6144 KB … We’ve done some test runs with the ’old’ kernel (linux-image-4.9.0-4-amd64) and the ’new’ one (linux-image-4.9.0-5-amd64). No. of tests: 6014 No. of result checks: 253555 (checking column values, stored procedure results, etc.) Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) The database file and the tmp directory located on ramdisk. András __________ Information from ESET Mail Security, version of virus signature database 16706 (20180109) __________ The message was checked by ESET Mail Security. http://www.eset.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel |
|
From: Mark R. <ma...@la...> - 2018-01-09 11:36:59
|
On 9-1-2018 11:25, Sergey Mereutsa wrote: > Hi! > > Just for your information - if this is your own dedicated server and you > do NOT run untrusted code on it (which can potentially steal your data > and send to someone) - you can safely disable this patch. > > Just because you do not defend yourself from yourself :) > > Both vulnerabilities are LOCAL :) And that is just plain bad advice, it can be exploited by any code running local on your machine. So anything on that machine that could have a remote code execution vulnerability, or just a plain malicious update, could then exploit it. Mark -- Mark Rotteveel |
|
From: Dimitry S. <sd...@ib...> - 2018-01-09 11:40:35
|
09.01.2018 12:36, Mark Rotteveel wrote: > it can be exploited by any code running local on your machine. So anything on that machine > that could have a remote code execution vulnerability, or just a plain malicious update, > could then exploit it. Anything that can have such vulnerability don't need tricky meltdown techniques to exploit database on local drive. -- WBR, SD. |
|
From: Mark R. <ma...@la...> - 2018-01-09 11:44:51
|
On 9-1-2018 12:40, Dimitry Sibiryakov wrote: > 09.01.2018 12:36, Mark Rotteveel wrote: >> it can be exploited by any code running local on your machine. So >> anything on that machine that could have a remote code execution >> vulnerability, or just a plain malicious update, could then exploit it. > > Anything that can have such vulnerability don't need tricky meltdown > techniques to exploit database on local drive. Sure, but by that logic you wouldn't need to defend against anything but the simplest security vulnerabilities. The problem with meltdown and spectre is that it could potentially allow you to gather information that the exploited process would normally not be able to access. Mark -- Mark Rotteveel |
|
From: Dimitry S. <sd...@ib...> - 2018-01-09 11:48:52
|
09.01.2018 12:44, Mark Rotteveel wrote: > The problem with meltdown and spectre is that it could potentially allow you to gather > information that the exploited process would normally not be able to access. AFAIU, all that I can get from that is some (kilo)bytes from random memory area. Mostly it would be random binary garbage which can be hardly interpreted as something useful. -- WBR, SD. |
|
From: Jiří Č. <ji...@ci...> - 2018-01-10 07:45:02
|
> AFAIU, all that I can get from that is some (kilo)bytes from random > memory area. Mostly > it would be random binary garbage which can be hardly interpreted as > something useful. Not exactly. Mostly you get some uninteresting garbage. But with enough time (matter or hours) you will get useful data (recall heartbleed issue). -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ |
|
From: Leyne, S. <Se...@br...> - 2018-01-09 15:34:43
|
András, > We've done some test runs with the 'old' kernel (linux-image-4.9.0-4- > amd64) and the 'new' one (linux-image-4.9.0-5-amd64). > > No. of tests: 6014 > No. of result checks: 253555 (checking column values, stored procedure > results, etc.) > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) > Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) While you results are interesting, and certainly "not good", they are not necessarily a reflection of global reality due to the age of your kernel. The performance impact of the recent fixes hinge, mainly, on whether the host OS/kernel has PCID support. PCID support was only added to linux kernel 4.14, released November 2017. It would be interesting for you to rerun the tests using the latest kernel. Sean |
|
From: Jiří Č. <ji...@ci...> - 2018-01-10 06:29:11
|
Here are some numbers based on pgbench: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ On Tue, Jan 9, 2018, at 16:34, Leyne, Sean wrote: > András, > > > We've done some test runs with the 'old' kernel (linux-image-4.9.0-4-> > amd64) and the 'new' one (linux-image-4.9.0-5-amd64). > > > > No. of tests: 6014 > > No. of result checks: 253555 (checking column values, stored > > procedure> > results, etc.) > > > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) > > Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) > > While you results are interesting, and certainly "not good", they are> not necessarily a reflection of global reality due to the age of your> kernel. > > The performance impact of the recent fixes hinge, mainly, on > whether the> host OS/kernel has PCID support. > > PCID support was only added to linux kernel 4.14, released > November 2017.> > It would be interesting for you to rerun the tests using the > latest kernel.> > > Sean > > > ---------------------------------------------------------------------- > --------> Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel |
|
From: Michal K. <mi...@mk...> - 2018-01-10 12:25:57
|
> The performance impact of the recent fixes hinge, mainly, on whether > the host OS/kernel has PCID support. First of all, the CPU must support PCID. > PCID support was only added to linux kernel 4.14, released November > 2017. ... and only to recent CPUs. Michal Kubecek |
|
From: marius a. p. <ma...@gm...> - 2018-01-10 14:01:34
|
Here are a few details on Linux related distros https://lwn.net/Articles/742999/ Also Intel already prepared microcode patches and they push it trough OS update channels https://hothardware.com/news/microsoft-windows-10-pcs-haswell-intel-cpus-significant-slowdowns-post-spectre-patch On Tue, Jan 9, 2018 at 11:52 AM, Omacht András <ao...@mv...> wrote: > Hi! > > > > Just for the shake of information. > > > > Our test system running on Debian 9.3. > > processor : 7 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Xeon(R) CPU E5420 @ 2.50GHz > stepping : 6 > microcode : 0x60b > cpu MHz : 2500.117 > cache size : 6144 KB > … > > > > We’ve done some test runs with the ’old’ kernel > (linux-image-4.9.0-4-amd64) and the ’new’ one (linux-image-4.9.0-5-amd64). > > > > No. of tests: 6014 > > No. of result checks: 253555 (checking column values, stored procedure > results, etc.) > > > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) > > Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) > > > > The database file and the tmp directory located on ramdisk. > > > > András > > > __________ Information from ESET Mail Security, version of virus signature > database 16706 (20180109) __________ > > The message was checked by ESET Mail Security. > http://www.eset.com > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > > |
|
From: Omacht A. <ao...@mv...> - 2018-01-10 14:08:32
|
Sean, finally we choose the easiest way, backup the system and update it to Debian SID. # uname -a Linux firebirdtest 4.14.0-3-amd64 #1 SMP Debian 4.14.12-2 (2018-01-06) x86_64 GNU/Linux Average running time: 641 secs (10 mins 41 secs) András -----Original Message----- From: Leyne, Sean [mailto:Se...@br...] Sent: Tuesday, January 9, 2018 4:35 PM To: For discussion among Firebird Developers <fir...@li...> Subject: Re: [Firebird-devel] Meltdown and Spectre András, > We've done some test runs with the 'old' kernel (linux-image-4.9.0-4- > amd64) and the 'new' one (linux-image-4.9.0-5-amd64). > > No. of tests: 6014 > No. of result checks: 253555 (checking column values, stored > procedure results, etc.) > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) Average > running time on 4.9.0-5: 635 secs (10 mins 35 secs) While you results are interesting, and certainly "not good", they are not necessarily a reflection of global reality due to the age of your kernel. The performance impact of the recent fixes hinge, mainly, on whether the host OS/kernel has PCID support. PCID support was only added to linux kernel 4.14, released November 2017. It would be interesting for you to rerun the tests using the latest kernel. Sean ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel __________ Information from ESET Mail Security, version of virus signature database 16707 (20180109) __________ The message was checked by ESET Mail Security. http://www.eset.com __________ Information from ESET Mail Security, version of virus signature database 16713 (20180110) __________ The message was checked by ESET Mail Security. http://www.eset.com |
|
From: Leyne, S. <Se...@br...> - 2018-01-10 15:25:37
|
András, > -----Original Message----- > From: Omacht András [mailto:ao...@mv...] > Sent: Wednesday, January 10, 2018 9:08 AM > finally we choose the easiest way, backup the system and update it to > Debian SID. > > # uname -a > Linux firebirdtest 4.14.0-3-amd64 #1 SMP Debian 4.14.12-2 (2018-01-06) > x86_64 GNU/Linux > > Average running time: 641 secs (10 mins 41 secs) > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) Average > > running time on 4.9.0-5: 635 secs (10 mins 35 secs) Thanks for re-running your tests. It is most interesting that FB's post-patch numbers show a much larger impact (~36% slower) than the Postgres results (~24%). Sean |
|
From: Omacht A. <ao...@mv...> - 2018-01-10 15:55:05
|
Sean, the difference may also arise from the difference it the test methodology. We've tried to test a real-world case, so we ran the tests over LAN like a client-server application (as we know the use of the network interface has also slowed down). Otherwise the test logic is simple: - we have a databases filled up some test data - at every test we - start one or two (e.g. lock test) transaction(s) - prepare some test data if needed (insert new data, update the existing one, or sometimes delete, or leave the database as is) - run the business logic (insert/update data (sometimes over views) or run stored procedures) - check the expected result (compare table lines, or sp's resultset) - end at the and the test system DOES ROLLBACK (this is a very stange point, not a "normal" usage, but we count on the starting database at next time...) I'm 100% sure this is not a general test procedure, which maybe was run on PostgreSQL. András -----Original Message----- From: Leyne, Sean [mailto:Se...@br...] Sent: Wednesday, January 10, 2018 4:26 PM To: For discussion among Firebird Developers <fir...@li...> Subject: Re: [Firebird-devel] Meltdown and Spectre András, > -----Original Message----- > From: Omacht András [mailto:ao...@mv...] > Sent: Wednesday, January 10, 2018 9:08 AM > finally we choose the easiest way, backup the system and update it to > Debian SID. > > # uname -a > Linux firebirdtest 4.14.0-3-amd64 #1 SMP Debian 4.14.12-2 (2018-01-06) > x86_64 GNU/Linux > > Average running time: 641 secs (10 mins 41 secs) > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) Average > > running time on 4.9.0-5: 635 secs (10 mins 35 secs) Thanks for re-running your tests. It is most interesting that FB's post-patch numbers show a much larger impact (~36% slower) than the Postgres results (~24%). Sean ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel __________ Information from ESET Mail Security, version of virus signature database 16713 (20180110) __________ The message was checked by ESET Mail Security. http://www.eset.com __________ Information from ESET Mail Security, version of virus signature database 16714 (20180110) __________ The message was checked by ESET Mail Security. http://www.eset.com |
|
From: Dmitry Y. <fir...@ya...> - 2018-01-10 15:39:06
|
10.01.2018 18:25, Leyne, Sean wrote: > > It is most interesting that FB's post-patch numbers show a much larger impact (~36% slower) than the Postgres results (~24%). Tests are different, so results cannot be compared "as is". Dmitry |
|
From: Leyne, S. <Se...@br...> - 2018-01-10 15:43:23
|
> 10.01.2018 18:25, Leyne, Sean wrote: > > > > It is most interesting that FB's post-patch numbers show a much larger > impact (~36% slower) than the Postgres results (~24%). > > Tests are different, so results cannot be compared "as is". I appreciate that the tests are different, I was commenting on the relative performance impact. |
|
From: Dmitry Y. <fir...@ya...> - 2018-01-10 16:02:47
|
10.01.2018 18:43, Leyne, Sean пишет: > >> Tests are different, so results cannot be compared "as is". > > I appreciate that the tests are different, I was commenting on the relative performance impact. Slowdown mostly depends on % of syscalls. R/O vs R/W tests would show different relative impact due to different lock contention. Big page cache (thus less I/O calls, even if resolved by the filesystem cache) vs small page cache - also different relative impact. Different workloads - also different relative impact. Dmitry |
|
From: Carlos H. C. <li...@wa...> - 2018-01-10 17:21:37
|
I saw a performance comparison (using comercial benchmarks tools, not specific for databases) and the most impact seems to be on Disk (even SSD), followed by RAM and CPU. The only area that isn't impacted seems to be GPU. []s Carlos http://www.firebirdnews.org FireBase - http://www.FireBase.com.br DY> 10.01.2018 18:43, Leyne, Sean пишет: >> >>> Tests are different, so results cannot be compared "as is". >> >> I appreciate that the tests are different, I was commenting on the relative performance impact. DY> Slowdown mostly depends on % of syscalls. R/O vs R/W tests would show DY> different relative impact due to different lock contention. Big page DY> cache (thus less I/O calls, even if resolved by the filesystem cache) vs DY> small page cache - also different relative impact. Different workloads - DY> also different relative impact. DY> Dmitry |
|
From: Jiří Č. <ji...@ci...> - 2018-01-10 18:37:04
|
Anything doing a lot of user-mode to kernel-mode transitions is affected the most. That's why i.e. IO intensive code suffers more than just computations. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ On Wed, Jan 10, 2018, at 17:47, Carlos H. Cantu wrote: > I saw a performance comparison (using comercial benchmarks tools, not> specific for databases) and the most impact seems to be on Disk (even> SSD), followed by RAM and CPU. The only area that isn't impacted seems> to be GPU. > > []s > Carlos > http://www.firebirdnews.org > FireBase - http://www.FireBase.com.br > > DY> 10.01.2018 18:43, Leyne, Sean пишет: > >> > >>> Tests are different, so results cannot be compared "as is". > >> > >> I appreciate that the tests are different, I was commenting on the > >> relative performance impact.> > DY> Slowdown mostly depends on % of syscalls. R/O vs R/W tests would > DY> show> DY> different relative impact due to different lock contention. Big > DY> page> DY> cache (thus less I/O calls, even if resolved by the filesystem > DY> cache) vs> DY> small page cache - also different relative impact. Different > DY> workloads -> DY> also different relative impact. > > DY> Dmitry > > > ---------------------------------------------------------------------- > --------> Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel |
|
From: Gabor B. <mln...@bg...> - 2018-10-14 08:26:42
|
2018. 01. 09. 10:52 keltezéssel, Omacht András írta: > The database file and the tmp directory located on ramdisk. What was the filesystem of the ramdisk? Tmpfs? Gabor |
|
From: Omacht A. <ao...@mv...> - 2018-10-15 11:05:01
|
Hi Gábor! df -Th | grep ram tmpfs tmpfs 15G 820M 15G 6% /ramdisk András -----Original Message----- From: Gabor Boros <mln...@bg...> Sent: Sunday, October 14, 2018 10:26 AM To: fir...@li... Subject: Re: [Firebird-devel] Meltdown and Spectre 2018. 01. 09. 10:52 keltezéssel, Omacht András írta: > The database file and the tmp directory located on ramdisk. What was the filesystem of the ramdisk? Tmpfs? Gabor Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel __________ Information from ESET Mail Security, version of virus signature database 18211 (20181014) __________ The message was checked by ESET Mail Security. http://www.eset.com __________ Information from ESET Mail Security, version of virus signature database 18216 (20181015) __________ The message was checked by ESET Mail Security. http://www.eset.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X