特性优化处理

发布时间:2018-12-19  栏目:MySQL  评论:0 Comments

 1 mysql> show global variables like '%binlog_cache%';
 2 +-----------------------+-----------+
 3 | Variable_name | Value |
 4 +-----------------------+-----------+
 5 | binlog_cache_size | 16777216 |
 6 | max_binlog_cache_size | 268435456 |
 7 +-----------------------+-----------+
 8 2 rows in set (0.00 sec)
 9 
10 mysql> show global status like '%binlog_cache%';
11 +-----------------------+-------+
12 | Variable_name | Value |
13 +-----------------------+-------+
14 | Binlog_cache_disk_use | 1 |
15 | Binlog_cache_use | 15 |
16 +-----------------------+-------+
17 2 rows in set (0.00 sec)
18 
19 mysql> set @@global.max_binlog_cache_size=300000000;
20 Query OK, 0 rows affected, 1 warning (0.00 sec)
21 
22 [root@172-16-3-190 shells]# bash +x load_data_into.sh          
23                 文件的总数为:1 
24                 文件名为:/tmp/load/HAOHUAN.txt 
25 当前正在处理的文件是:/tmp/load/HAOHUAN.txt
26 load data infile '/tmp/load/HAOHUAN.txt' into table practice.temp_baofoo_unbind fields terminated by ',' lines terminated by '\n' (merchant_no,bank_code,bank_card,protocol_no)
27 Warning: Using a password on the command line interface can be insecure.
28 ERROR 1197 (HY000) at line 1: Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again
29 
30 mysql> show global status like '%binlog_cache%';         
31 +-----------------------+-------+
32 | Variable_name | Value |
33 +-----------------------+-------+
34 | Binlog_cache_disk_use | 2 |
35 | Binlog_cache_use | 16 |
36 +-----------------------+-------+
37 2 rows in set (0.00 sec)

性能优化处理


图的特性优化

  • 一个activity 空置时
    只需要3M之空间(当然这里是连Application所占有的上空的)

事例:本地添加一个比老的觊觎,900K ,在登录突显的上
直接加载这张图(加载的点子 是平昔拿走当地的drawable 和
bitmap),看内存消耗,80M。

  • 一贯加载drawable 消耗内存21M

  • 间接加载bitmap(编码格式是AGB8888 一个如素点占4只字节)
    消耗内存21m(大图展现不全 有白边)

    对图片的实行拍卖

  • 本着Bitmap做编码格式的处理(AGB565 一个诸如素点占2独字节) 消耗内存5M
    (效果以及 AGB8888差不多,且没有白边)针对当前意况把图片放置于不同之drawable的密度下,看看加载的动静(加载时内存消耗一致
    不过暨 将图片放置在drawable中不一致 在drawable中会转移死)
    1)drawable-hdpi下 5.26M
    1)drawable-xhdpi下 5.26M
    1)drawable-xxhdpi下 5.26M
    今非昔比分辨率下之图纸加载 耗费内存:
    1)扩张分辨率之后 耗费内存是 8.02M

    针对图片处理,建议1.在不太要求精度的情况下 ,尽量使用AGB565处理 2.图片进行分类,放置在drawable-hdpi drawable-xhdpi下 drawable-xxhdpi下
    

2 内存以的优化
1)多少个Context的认:(上下文,就是能取得到系统资源的类)
a)结构如下;
-Object
-Context
-MockContext
-ContextWrapper
-TintContextWrapper
-IsolatedContext
-MutableContextWrapper
-ContextThemeWrapper
-Activity ———————–
-Service ———————–
-Application———————–
-BackupAgent
头的几单Context是时用到之Activity Service(Service) Application

b)生命周期:
  Application 是在一个在app启动时就创建的context实例,并且application会一直存在,直到用户将其杀死。
  Activity 正常情况下,一个activity的生命周期是随着启动时创建,在不再使用,应该退出activity栈时,就会被销毁
  Service 正常情况下 service在启动时创建,在停止时终止。(service 和ntentService 的生命周期 有区别,service是可以自己stopSelf 也可以通过Intent停止服务,
          但是IntentService是跟绑定的宿主生命周期关联,会随着宿主的生命周期的结束而结束自己的生命周期)
c)获取
 在Activity中,直接使用Activity.this,getBaseContext(){因为Activity都是ContextWrapper的基类,所以这里的getBaseContext都是获取基类中的mBase参数},
 看老罗的博客中 得到这样的一个结果:activity是一个context,activity的父类是ContextWrapperTheme,而ContextWrapperTheme的父类是ContextWrapper,ContextWrapper的父类是Context.
  在ContextWrapper 中有一个方法也是获取Context的,叫getBaseContext() 返回的是类变量mBase,这个Context是在Activity创建是 系统创建的,与Activity是两个不同的Context。
  通过分配的内存地址可以看出,两个不一样。
  Activity的创建 不是通过new一个对象这么简单的创建,看代码是
  public class Instrumentation {  
    ......  

    public Activity newActivity(ClassLoader cl, String className,  
            Intent intent)  
            throws InstantiationException, IllegalAccessException,  
            ClassNotFoundException {  
        return (Activity)cl.loadClass(className).newInstance();  
    }  

    ......  
} 是通过class.newInstance()来创建的。Activity是一个复杂的类,包含了很多东西。是在ActivityThread 中创建的,创建过程可以看看源码:
public final class ActivityThread {  
......  

Instrumentation mInstrumentation;  
......  

private final Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {  
    ......  

    ComponentName component = r.intent.getComponent();  
    ......  

    Activity activity = null;  
    try {  
        java.lang.ClassLoader cl = r.packageInfo.getClassLoader();  
        activity = mInstrumentation.newActivity(  
                cl, component.getClassName(), r.intent);  
        ......  
    } catch (Exception e) {  
        ......  
    }  

    try {  
        Application app = r.packageInfo.makeApplication(false, mInstrumentation);  
        ......  

        if (activity != null) {  
            ContextImpl appContext = new ContextImpl();  
            ......  
            appContext.setOuterContext(activity);  
            ......  
            Configuration config = new Configuration(mConfiguration);  
            ......  

            activity.attach(appContext, this, getInstrumentation(), r.token,  
                    r.ident, app, r.intent, r.activityInfo, title, r.parent,  
                    r.embeddedID, r.lastNonConfigurationInstance,  
                    r.lastNonConfigurationChildInstances, config);  
            ......  

            mInstrumentation.callActivityOnCreate(activity, r.state);  

            ......    
        }  

        ......  
    } catch (SuperNotCalledException e) {  
        ......  
    } catch (Exception e) {  
        ......  
    }  

    return activity;  
}  

} 这里创办了累累底事物,大家的Context 和 getBasseContext
之所以不同,在那边就暴发反映。
并且这里尚创办了一个Application
这样一个ApplicationContext,这样ApplicationContext 和 从前
所说之星星单Activity 及getBaseContext分别是无雷同的。

d)在Service中 获取的Context 和getBaseContext 也是不同的地址,所以不是指的同一个变量。在Activity中启动Service之后,
  分别对Activity和Service获取Context 及 getBaseContext来比较,是个Context的地址都不一样。    
  启动Service的源码没有找到,但是看Service中存在的各变量和Activity中存在的各变量是类似,没有找到启动Service中 比较深层次的源码,
  所以这里不能给出确切的认定,service和Activity启动一样(只不过Activity中有Window可以承载UI,但是Service就不能)。

e)因为存在Context的生命周期的说法,所以这里要说的是创建某个对象时 如果这个对象是全局的,就应该要使用全局的Context,如果对象是局部的
  那么就应该要用局部的Context.
  内存泄漏的实例是:  推送的manager 及统计的manager 在创建的时候 是在引导页。而传入的Context直接就是引导页的this.导致
  推送的manager 统计的manager 因为是静态单例,所以就一直持有引导页的context,不被释放。导致内存泄漏。

  查看工具:
   AS中存在这样一个Dump java heap的工具,这个工具能抓取手机中正在运行的 所有应用的在内存中15秒的分配情况。通过class package 可以很方便的找到
   当前的应用的包下存在哪些对象,对象的个数。
1 [root@172-16-3-190 shells]# bash +x load_data_into.sh 
2                 文件的总数为:1 
3                 文件名为:/tmp/load/HAOHUAN.txt 
4 当前正在处理的文件是:/tmp/load/HAOHUAN.txt
5 load data infile '/tmp/load/HAOHUAN.txt' into table practice.temp_baofoo_unbind fields terminated by ',' lines terminated by '\n' (merchant_no,bank_code,bank_card,protocol_no)
6 Warning: Using a password on the command line interface can be insecure.
7 ERROR 1197 (HY000) at line 1: Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again

【故障排查】

迫于直接扩展max_binlog_cache_size的价值到500M时问题才化解(后经test实际为到400M也可load成功),然则slave上的价值没有立时变更,由此SQL同步线程报错,stop同步线程,同master一样的改后,同步才总算正常

 
通过下边论以load的道导入数据平日,出现多实践务需要之max_binlog_cache_size空间不足。该数据文件HAOHUAN.txt只含以逗号分隔的500万行左右底多少,每行四列,文件大小为270M。

  max_binlog_cache_size参数时动态参数,该值的安好参考binlog_cache_use的轻重来对号入座增添。load导入或者delete数据的高低要要逾max_binlog_cache_size的价值,多行事务才会不负众望实施。该参数值修改后,注意要同布局文件被的价值大小相同。

max_binlog_cache_size设置的参考标准

1197基本上语词事务要求重新老的max_binlog_cache_size报错

【故障总结】

  binlog_cache_size:为每个session
分配的内存,在工作进程遭到因故来囤二迈入制日志的缓存,提升记录bin-log的频率。没有啊非凡业务,dml也不是相当频繁的景下好安装粗一些,要是工作特别又多,dml操作为再三,则可适量的调大一点。

 1 mysql> set @@global.max_binlog_cache_size=500000000;
 2 Query OK, 0 rows affected, 1 warning (0.00 sec)
 3 
 4 mysql> show slave status \G;
 5 *************************** 1. row ***************************
 6                Slave_IO_State: Waiting for master to send event
 7                   Master_Host: 172.16.3.190
 8                   Master_User: repl
 9                   Master_Port: 3309
10                 Connect_Retry: 30
11               Master_Log_File: binlog.000018
12           Read_Master_Log_Pos: 120
13                Relay_Log_File: relay_bin.000006
14                 Relay_Log_Pos: 6973
15         Relay_Master_Log_File: binlog.000017
16              Slave_IO_Running: Yes
17             Slave_SQL_Running: Yes
18               Replicate_Do_DB: 
19           Replicate_Ignore_DB: 
20            Replicate_Do_Table: 
21        Replicate_Ignore_Table: 
22       Replicate_Wild_Do_Table: 
23   Replicate_Wild_Ignore_Table: 
24                    Last_Errno: 1197
25                    Last_Error: Could not execute Write_rows event on table practice.temp_baofoo_unbind; Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again, Error_code: 1197; Writing one row to the row-based binary log failed, Error_code: 1534; handler error HA_ERR_RBR_LOGGING_FAILED; the event's master log binlog.000017, end_log_pos 268602107
26                  Skip_Counter: 0
27           Exec_Master_Log_Pos: 11408
28               Relay_Log_Space: 333526981
29               Until_Condition: None
30                Until_Log_File: 
31                 Until_Log_Pos: 0
32            Master_SSL_Allowed: No
33            Master_SSL_CA_File: 
34            Master_SSL_CA_Path: 
35               Master_SSL_Cert: 
36             Master_SSL_Cipher: 
37                Master_SSL_Key: 
38         Seconds_Behind_Master: 208
39 Master_SSL_Verify_Server_Cert: No
40                 Last_IO_Errno: 0
41                 Last_IO_Error: 
42                Last_SQL_Errno: 1197
43                Last_SQL_Error: Could not execute Write_rows event on table practice.temp_baofoo_unbind; Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again, Error_code: 1197; Writing one row to the row-based binary log failed, Error_code: 1534; handler error HA_ERR_RBR_LOGGING_FAILED; the event's master log binlog.000017, end_log_pos 268602107
44   Replicate_Ignore_Server_Ids: 
45              Master_Server_Id: 1903309
46                   Master_UUID: 1b589d80-f450-11e7-9150-525400f4ecb2
47              Master_Info_File: /opt/app/mysql_3309/logs/master.info
48                     SQL_Delay: 0
49           SQL_Remaining_Delay: NULL
50       Slave_SQL_Running_State: Reading event from the relay log
51            Master_Retry_Count: 86400
52                   Master_Bind: 
53       Last_IO_Error_Timestamp: 
54      Last_SQL_Error_Timestamp: 180803 17:39:08
55                Master_SSL_Crl: 
56            Master_SSL_Crlpath: 
57            Retrieved_Gtid_Set: 
58             Executed_Gtid_Set: 
59                 Auto_Position: 0
60 1 row in set (0.00 sec)
61 
62 mysql> stop slave;
63 Query OK, 0 rows affected (1 min 10.64 sec)

 
查看max_binlog_cache_size的轻重缓急,发现数据文件的轻重缓急确实于max_binlog_cache_size的价倘使稍微,假使max_binlog_cache_size的深浅不足以存放事务的binlog,那么会现用磁盘临时文件来存放binlog,通过查看Binlog_cache_disk_use发现用临时文件存放的次数为1。因而增大max_binlog_cache_size的价到300M,又一次实施脚本发现仍旧报相同之荒唐。且下临时文件的次数为2,使用临时文件的存放binlog的终究次数也相应由15加及了16不成。

【故障情景】

 
Binlog_cache_disk_use表示因为大家binlog_cache_size设计的内存不足导致缓存二上前制日志用到了临时文件的次数;Binlog_cache_use
表示用binlog_cache_size缓存的次数,当对应的Binlog_cache_disk_use
值比较非凡的下 大家好设想当的调整高 binlog_cache_size
对应的价

留下评论

网站地图xml地图