These are chat archives for ManageIQ/manageiq/performance

26th
Oct 2018
Daniel Berger
@djberg96
Oct 26 2018 16:49
@NickLaMuro what's the mem usage per property on a rails model object roughly?
i'm wondering if moving a bunch of vmware columns/properties to their own sub-table and using STI would be beneficial or not worth the hassle
Nick LaMuro
@NickLaMuro
Oct 26 2018 16:50
uh... I would have to check on that I guess
that said, I think it is vastly different depending on the table
my guess is vms is much more costly than say users
Daniel Berger
@djberg96
Oct 26 2018 16:50
you mean you don't have the information handy off the top of your head?!
j/k
Nick LaMuro
@NickLaMuro
Oct 26 2018 16:57

i'm wondering if moving a bunch of vmware columns/properties to their own sub-table and using STI would be beneficial or not worth the hassle

What I will say with this is that we probably would gain just as much by maybe just putting a SELECT only, the, columns, we, need when that makes sense instead of trying to re-architect the database

Daniel Berger
@djberg96
Oct 26 2018 16:58
But I'm lazy!
is there a way to set the default selectable columns at the model level?
Nick LaMuro
@NickLaMuro
Oct 26 2018 17:03
you can do a default_scope
NickLaMuro @NickLaMuro has to look up if that is the right Rails DSL method...
Daniel Berger
@djberg96
Oct 26 2018 17:03
ooh, that looks promising
wonder if you can invert it, i.e. ignore
Nick LaMuro
@NickLaMuro
Oct 26 2018 17:05
you have to do .unscoped I think, but yeah
Daniel Berger
@djberg96
Oct 26 2018 17:08
Hm, guess i'm not seeing how to apply it
Keenan Brock
@kbrock
Oct 26 2018 17:08
Could we just get rid of STI? :bomb: :runner:
Nick LaMuro
@NickLaMuro
Oct 26 2018 17:10
Daniel Berger
@djberg96
Oct 26 2018 17:10
i mean .unscoped
Nick LaMuro
@NickLaMuro
Oct 26 2018 17:19
irb(main):001:0> Vm.all.to_sql
#=> SELECT \"vms\".* FROM \"vms\" 
#=> WHERE \"vms\".\"type\" IN (
#=>   'Vm', 'VmServer', 'ManageIQ::Providers::InfraManager::Vm', 'ManageIQ::Providers::CloudManager::Vm',
#=>   'VmXen', 'ManageIQ::Providers::Kubevirt::InfraManager::Vm', 'ManageIQ::Providers::Redhat::InfraManager::Vm',
#=>   'ManageIQ::Providers::Microsoft::InfraManager::Vm', 'ManageIQ::Providers::Vmware::InfraManager::Vm',
#=>   'ManageIQ::Providers::Amazon::CloudManager::Vm', 'ManageIQ::Providers::Azure::CloudManager::Vm',
#=>   'ManageIQ::Providers::Google::CloudManager::Vm', 'ManageIQ::Providers::Openstack::CloudManager::Vm',
#=>   'ManageIQ::Providers::Vmware::CloudManager::Vm') AND \"vms\".\"template\" = 'f'
irb(main):002:0> Vm.unscoped.to_sql
#=> SELECT \"vms\".* FROM \"vms\" 
#=> WHERE \"vms\".\"type\" IN (
#=>   'Vm', 'VmServer', 'ManageIQ::Providers::InfraManager::Vm', 'ManageIQ::Providers::CloudManager::Vm',
#=>   'VmXen', 'ManageIQ::Providers::Kubevirt::InfraManager::Vm', 'ManageIQ::Providers::Redhat::InfraManager::Vm',
#=>   'ManageIQ::Providers::Microsoft::InfraManager::Vm', 'ManageIQ::Providers::Vmware::InfraManager::Vm',
#=>   'ManageIQ::Providers::Amazon::CloudManager::Vm', 'ManageIQ::Providers::Azure::CloudManager::Vm',
#=>   'ManageIQ::Providers::Google::CloudManager::Vm', 'ManageIQ::Providers::Openstack::CloudManager::Vm',
#=>   'ManageIQ::Providers::Vmware::CloudManager::Vm')
irb(main):003:0>
(formatted to make it a little easier to parse)
Keenan Brock
@kbrock
Oct 26 2018 17:26
note: I prefer using VmOrTemplate when I am showing sample code
Removing that type clause makes things easier to understand. But maybe that was your point Nick
Nick LaMuro
@NickLaMuro
Oct 26 2018 17:28
@kbrock I know this, but VmOrTemplate doesn't have a default_scope, which was the part of the demo...
Keenan Brock
@kbrock
Oct 26 2018 17:28
+1
Daniel Berger
@djberg96
Oct 26 2018 17:34
My experiments how a 16kb savings per VM object when I select only the fields relevant to Azure.
If objspace is to be trusted
(144 vs 128)
i guess that's bytes, not kb
Daniel Berger
@djberg96
Oct 26 2018 17:42
might be more performant, too
Nick LaMuro
@NickLaMuro
Oct 26 2018 17:42
10% is still pretty good when we are talking about a lot of VMs though
Daniel Berger
@djberg96
Oct 26 2018 17:42
if nothing else, it's easier to read in the console :)
yeah, maybe i'll push that up as a wip today
see what kind of feedback i get
Daniel Berger
@djberg96
Oct 26 2018 17:58
ends up trying to do select count(col1, col2, col3, ...)
Adam Grare
@agrare
Oct 26 2018 18:50

If objspace is to be trusted
(144 vs 128)

@djberg96 I think that is a number of objects, not bytes

so it could be 64 bytes if each object is an integer :)
its hard to get hard numbers from objspace on object size in my experience
Joe Rafaniello
@jrafanie
Oct 26 2018 18:56
yeah, I think you're better off creating millions of the same objects before and after and compare process size from the OS perspective
Only number of allocations could be helpful from objspace... even that would need to be weighed vs. memory/cpu because high allocations doesn't indicate a "worse" design
Adam Grare
@agrare
Oct 26 2018 19:15

yeah, I think you're better off creating millions of the same objects before and after and compare process size from the OS perspective

:+1: you could use MiqProcess.processInfo[:proportional_set_size] to introspect the test process mem usage

or s/proportional_set_size/memory_usage/ if you are using a mac
Joe Rafaniello
@jrafanie
Oct 26 2018 19:23
yeah, exactly