標籤: USB CONNECTOR 

附010.Kubernetes永久存儲之GlusterFS超融合部署

admin

一 前期準備

1.1 基礎知識


在Kubernetes中，使用GlusterFS文件系統，操作步驟通常是：

創建brick–>創建volume–>創建PV–>創建PVC–>Pod掛載PVC

如果要創建多個PV，則需要手動重複執行，可通過Heketi管理glusterfs。

Heketi是用來管理GlusterFS卷的生命周期的，並提供了一個RESTful API接口供Kubernetes調用，因為GlusterFS沒有提供API調用的方式，所以我們藉助heketi。通過Heketi，Kubernetes可以動態配置GlusterFS卷，Heketi會動態在集群內選擇bricks創建所需的volumes，確保數據的副本會分散到集群不同的故障域內，同時Heketi還支持GlusterFS多集群管理，便於管理員對GlusterFS進行操作。

Heketi要求在每個glusterfs節點上配備裸磁盤，用於Heketi創建PV和VG。通過Hekete，Kubernetes中使用PV步驟為：

創建StorageClass–>創建PVC–>Pod掛載PVC

這種方式稱為基於StorageClass的動態資源供應。

提示：本實驗基於Kubernetes部署glusterfs，同時glusterfs管理組件Heketi也使用Kubernetes部署。

1.2 架構示意



提示：本實驗不涉及Kubernetes部署，Kubernetes部署參考001-019。

1.3 相關規劃






主機

IP

磁盤

備註

k8smaster01

172.24.8.71

Kubernetes master節點

k8smaster02

172.24.8.72

Kubernetes master節點

k8smaster03

172.24.8.73

Kubernetes master節點

k8snode01

172.24.8.74

sdb

Kubernetes node節點

glusterfs節點

k8snode02

172.24.8.75

sdb

Kubernetes node節點

glusterfs節點

k8snode03

172.24.8.76

sdb

Kubernetes node節點

glusterfs節點

磁盤規劃

k8snode01 k8snode02 k8snode03
PV sdb1 sdb1 sdb1





1.4 部署條件

超融合部署需要具有已經部署的Kubernetes集群管理訪問權限。如果Kubernetes節點滿足以下要求，則可以選擇將GlusterFS作為超融合服務部署：

  • 必須至少有三個節點用於glusterfs；

  • 每個節點必須至少連接一個裸磁盤設備，以供heketi使用。這些設備上不得包含任何數據，heketi將會格式化和分區此設備；

  • 每個節點必須打開以下端口才能進行GlusterFS通信：

    • 2222：GlusterFS pod的sshd端口；

    • 24007：GlusterFS守護程序；

    • 24008：GlusterFS管理；

    • 49152——49251：主機上每個卷的每個brick都需要有獨立的端口。對於每塊新brick，將從49152開始使用一個新端口。建議每台主機的默認範圍為49152-49251，也可根據需要進行調整。

  • 必須加載以下內核模塊：

    • dm_snapshot

    • dm_mirror

    • dm_thin_pool

  • 對於內核模塊，可通過lsmod | grep <name>查看模塊是否存在，並modprobe <name>加載給定的模塊。

  • 每個節點都要求該mount.glusterfs命令可用。在所有基於Red Hat的操作系統下，此命令由glusterfs-fuse軟件包提供。


注意：節點上安裝的GlusterFS客戶端版本應盡可能接近服務器的版本。要獲取已安裝的版本，可通過glusterfs –version或kubectl exec <pod> — glusterfs –version命令查看。

1.5 其他準備


所有節點NTP配置；

所有節點添加相應主機名解析：

  1 172.24.8.71 k8smaster01
  2 172.24.8.72 k8smaster02
  3 172.24.8.73 k8smaster03
  4 172.24.8.74 k8snode01
  5 172.24.8.75 k8snode02
  6 172.24.8.76 k8snode03



注意：若非必要，建議關閉防火牆和SELinux。

二 規劃裸設備

2.1 確認磁盤

  1 [root@k8snode01 ~]# fdisk /dev/sdb -l		#檢查sdb是否為裸磁盤

三 安裝glusterfs-fuse

3.1 安裝相應RPM源

  1 [root@k8snode01 ~]# yum -y install centos-release-gluster
  2 [root@k8snode01 ~]# yum -y install glusterfs-fuse		#安裝glusterfs-fuse



提示：k8snode01、k8snode02、k8snode03類似操作，根據1.4要求安裝glusterfs-fuse組件；

安裝相應源之後，會在/etc/yum.repos.d/目錄多出文件CentOS-Storage-common.repo，內容如下：

# CentOS-Storage.repo

#

# Please see http://wiki.centos.org/SpecialInterestGroup/Storage for more

# information




[centos-storage-debuginfo]

name=CentOS-$releasever – Storage SIG – debuginfo

baseurl=http://debuginfo.centos.org/$contentdir/$releasever/storage/$basearch/

gpgcheck=1

enabled=0

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Storage

3.2 加載相應模塊

  1 [root@k8snode01 ~]# cat > /etc/sysconfig/modules/glusterfs.modules <<EOF
  2 #!/bin/bash
  3 
  4 for kernel_module in dm_snapshot dm_mirror dm_thin_pool;do
  5     /sbin/modinfo -F filename \${kernel_module} > /dev/null 2>&1
  6     if [ \$? -eq 0 ]; then
  7         /sbin/modprobe \${kernel_module}
  8     fi
  9 done;
 10 EOF
 11 [root@k8snode01 ~]# chmod +x /etc/sysconfig/modules/glusterfs.modules
 12 [root@k8snode01 ~]# lsmod |egrep "dm_snapshot|dm_mirror|dm_thin_pool"	#所有glusterfs node節點檢查



提示：可通過modprobe <name>加載給定的模塊。

四 Kubernetes部署glusterfs

4.1 Node tag

  1 [root@k8smaster01 ~]# kubectl label nodes k8snode01 storagenode=glusterfs
  2 [root@k8smaster01 ~]# kubectl label nodes k8snode02 storagenode=glusterfs
  3 [root@k8smaster01 ~]# kubectl label nodes k8snode03 storagenode=glusterfs




提示：在後續使用DaemonSet部署時候kube-templates/glusterfs-daemonset.yaml存在如下針對label的Selector：

spec:

nodeSelector:

storagenode: glusterfs

4.2 下載glusterfs-Kubernetes

  1 [root@k8smaster01 ~]# yum -y install git
  2 [root@k8smaster01 ~]# git clone https://github.com/gluster/gluster-kubernetes.git


4.3 修改glusterfs拓撲

  1 [root@k8smaster01 ~]# cd gluster-kubernetes/deploy/
  2 [root@k8smaster01 deploy]# cp topology.json.sample topology.json
  3 [root@k8smaster01 deploy]# vi topology.json


  1 {
  2   "clusters": [
  3     {
  4       "nodes": [
  5         {
  6           "node": {
  7             "hostnames": {
  8               "manage": [
  9                 "k8snode01"
 10               ],
 11               "storage": [
 12                 "172.24.8.74"
 13               ]
 14             },
 15             "zone": 1
 16           },
 17           "devices": [
 18             "/dev/sdb"
 19           ]
 20         },
 21         {
 22           "node": {
 23             "hostnames": {
 24               "manage": [
 25                 "k8snode02"
 26               ],
 27               "storage": [
 28                 "172.24.8.75"
 29               ]
 30             },
 31             "zone": 1
 32           },
 33           "devices": [
 34             "/dev/sdb"
 35           ]
 36         },
 37         {
 38           "node": {
 39             "hostnames": {
 40               "manage": [
 41                 "k8snode03"
 42               ],
 43               "storage": [
 44                 "172.24.8.76"
 45               ]
 46             },
 47             "zone": 1
 48           },
 49           "devices": [
 50             "/dev/sdb"
 51           ]
 52         }
 53       ]
 54     }
 55   ]
 56 }


提示：heketi配置文件及介紹參考《附009.Kubernetes永久存儲之GlusterFS獨立部署》。

若需要修改heketi的暴露方式，若需要修改為NodePort，可參考https://lichi6174.github.io/glusterfs-heketi/。

所有部署相關yaml位於/root/gluster-kubernetes/deploy/kube-templates，本實驗採用默認參數。

4.4 配置heketi

  1 [root@k8smaster01 deploy]# cp heketi.json.template heketi.json
  2 [root@k8smaster01 deploy]# vi heketi.json
  3 {
  4     "_port_comment": "Heketi Server Port Number",
  5     "port" : "8080",
  6 
  7     "_use_auth": "Enable JWT authorization. Please enable for deployment",
  8     "use_auth" : true,				#開啟用戶認證
  9 
 10     "_jwt" : "Private keys for access",
 11     "jwt" : {
 12         "_admin" : "Admin has access to all APIs",
 13         "admin" : {
 14             "key" : "admin123"			#管理員密碼
 15         },
 16         "_user" : "User only has access to /volumes endpoint",
 17         "user" : {
 18             "key" : "xianghy"			#用戶密碼
 19         }
 20     },
 21 
 22     "_glusterfs_comment": "GlusterFS Configuration",
 23     "glusterfs" : {
 24 
 25         "_executor_comment": "Execute plugin. Possible choices: mock, kubernetes, ssh",
 26         "executor" : "${HEKETI_EXECUTOR}",	        #本實驗使用Kubernetes方式
 27 
 28         "_db_comment": "Database file name",
 29         "db" : "/var/lib/heketi/heketi.db",	        #heketi數據存儲
 30 
 31         "kubeexec" : {
 32             "rebalance_on_expansion": true
 33         },
 34 
 35         "sshexec" : {
 36             "rebalance_on_expansion": true,
 37             "keyfile" : "/etc/heketi/private_key",
 38             "port" : "${SSH_PORT}",
 39             "user" : "${SSH_USER}",
 40             "sudo" : ${SSH_SUDO}
 41         }
 42     },
 43 
 44     "backup_db_to_kube_secret": false
 45 }


4.5 相關修正


新版Kubernetes的# kubectl get pod命令無–show-all選項，需要如下操作修正部署gk-deploy腳本。

  1 [root@k8smaster01 deploy]# vi gk-deploy
  2 924 #heketi_pod=$(${CLI} get pod --no-headers --show-all --selector="heketi" | awk '{print $1}')
  3 925 heketi_pod=$(${CLI} get pod --no-headers --selector="heketi" | awk '{print $1}')






由於國內glusterfs鏡像可能無法pull，建議通過VPN等方式提前pull鏡像，然後上傳至所有glusterfs node節點。

  1 [root@VPN ~]# docker pull gluster/gluster-centos:latest
  2 [root@VPN ~]# docker pull heketi/heketi:dev
  3 [root@VPN ~]# docker save -o gluster_latest.tar gluster/gluster-centos:latest
  4 [root@VPN ~]# docker save -o heketi_dev.tar heketi/heketi:dev
  5 [root@k8snode01 ~]# docker load -i gluster_latest.tar
  6 [root@k8snode01 ~]# docker load -i heketi_dev.tar
  7 [root@k8snode01 ~]# docker images
  8


4.6 正式部署

  1 [root@k8smaster01 deploy]# ./gk-deploy -h			#查看部署參數
  2 [root@k8smaster01 deploy]# kubectl create ns heketi		#建議部署在獨立的namespace中
  3 [root@k8smaster01 deploy]# ./gk-deploy -g -n heketi topology.json --admin-key admin123 --user-key xianghy
  4 ……
  5 Do you wish to proceed with deployment?
  6 
  7 [Y]es, [N]o? [Default: Y]: y





提示：部署腳本更多參數參考：https://github.com/gluster/gluster-kubernetes/blob/master/deploy/gk-deploy。

注意：若部署失敗，需要通過下方式徹底刪除后重新部署：

  1 [root@k8smaster01 deploy]# ./gk-deploy --abort --admin-key admin123 --user-key xianghy -y -n heketi
  2 [root@k8smaster01 deploy]# kubectl delete -f kube-templates/ -n heketi



glusterfs node節點需要執行如下徹底清理：

  1 [root@k8snode01 ~]# dmsetup ls
  2 [root@k8snode01 ~]# dmsetup remove_all
  3 [root@k8snode01 ~]# rm -rf /var/log/glusterfs/
  4 [root@k8snode01 ~]# rm -rf /var/lib/heketi
  5 [root@k8snode01 ~]# rm -rf /var/lib/glusterd/
  6 [root@k8snode01 ~]# rm -rf /etc/glusterfs/
  7 [root@k8snode01 ~]# dd if=/dev/zero of=/dev/sdb bs=512k count=1
  8 [root@k8snode01 ~]# wipefs -af /dev/sdb


4.7 Kubernetes集群查看驗證

  1 [root@k8smaster01 ~]# kubectl get nodes --show-labels | grep -E 'NAME|node'
  2 [root@k8smaster01 ~]# kubectl get all -n heketi




  1 [root@k8smaster01 ~]# kubectl get pods -o wide -n heketi



4.8 gluster集群查看驗證

  1 [root@k8smaster01 ~]# kubectl exec -it heketi-65f4555d74-72hrf -n heketi -- heketi-cli cluster list --user admin --secret admin123								#集群列表
  2 [root@k8smaster01 ~]# kubectl -n heketi exec -ti heketi-65f4555d74-72hrf /bin/bash                               [root@heketi-65f4555d74-72hrf /]# heketi-cli cluster list --user admin --secret admin123	#進入heketi容器查看
  3 [root@k8smaster01 ~]# curl http://10.254.111.219:8080/hello
  4 Hello from Heketi



注意：使用4.6腳本為一鍵部署，也可使用gluster-kubernetes/deploy/目錄下的文件，分開逐步部署，整理部署思路如下：

  1. 使用glusterfs-daemonset.json部署glusterfs DaemonSet；

  2. 對node節點進行打標籤；

  3. 使用heketi-service-account.json部署Heketi的服務帳戶；

  4. 對Heketi所創建的服務帳戶授權；

  5. 創建secret；

  6. 轉發本地8080端口至deploy-heketi。


獨立部署完整過程參考：https://jimmysong.io/kubernetes-handbook/practice/using-heketi-gluster-for-persistent-storage.html。

五 安裝heketi-cli


由於在master節點管理heketi需要進入heketi容器或者使用kubectl exec -ti 方式，建議直接在master節點安裝heketi客戶端，直接管理、

5.1 安裝heketi服務

  1 [root@k8smaster01 ~]# yum -y install centos-release-gluster
  2 [root@k8smaster01 ~]# yum -y install heketi-client


5.2 配置heketi

  1 [root@k8smaster01 ~]# echo "export HEKETI_CLI_SERVER=http://$(kubectl get svc heketi -n heketi -o go-template='{{.spec.clusterIP}}'):8080" >> /etc/profile.d/heketi.sh
  2 [root@k8smaster01 ~]# echo "alias heketi-cli='heketi-cli --user admin --secret admin123'" >> ~/.bashrc
  3 [root@k8smaster01 ~]# source /etc/profile.d/heketi.sh
  4 [root@k8smaster01 ~]# source ~/.bashrc
  5 [root@k8smaster01 ~]# echo $HEKETI_CLI_SERVER
  6 http://heketi:8080


5.3 集群管理

  1 [root@k8smaster01 ~]# heketi-cli cluster list
  2 Clusters:
  3 Id:67004a06fbcb4fa525bcec1fbaa9ef2d [file][block]
  4 [root@k8smaster01 ~]# heketi-cli cluster info 67004a06fbcb4fa525bcec1fbaa9ef2d	#集群詳細信息
  5 Cluster id: 67004a06fbcb4fa525bcec1fbaa9ef2d
  6 Nodes:
  7 40cdd4c1d0c389939193d6dea3c5bfe8
  8 62873c54cf61025fda91e6d44433378b
  9 d48986357840d28653304e7170599da5
 10 Volumes:
 11 5f15f201d623e56b66af56313a1975e7
 12 Block: true
 13 
 14 File: true
 15 [root@k8smaster01 ~]# heketi-cli topology info 67004a06fbcb4fa525bcec1fbaa9ef2d	#查看拓撲信息
 16 [root@k8smaster01 ~]# heketi-cli node list					        #查看所有node
 17 Id:40cdd4c1d0c389939193d6dea3c5bfe8     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 18 Id:62873c54cf61025fda91e6d44433378b     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 19 Id:d48986357840d28653304e7170599da5     Cluster:67004a06fbcb4fa525bcec1fbaa9ef2d
 20 [root@k8smaster01 ~]# heketi-cli node info 40cdd4c1d0c389939193d6dea3c5bfe8  	#node節點信息
 21 [root@k8smaster01 ~]# heketi-cli volume create --size=2 --replica=2		        #默認為3副本的replica模式



  1 [root@k8smaster01 ~]# heketi-cli volume list					#列出所有卷
  2 [root@k8smaster01 ~]# heketi-cli volume info fc296ab350dcc36e00dd3b3643a04645	#卷信息
  3 [root@k8smaster01 ~]# heketi-cli volume delete fc296ab350dcc36e00dd3b3643a04645	#刪除卷


六 Kubernetes動態掛載glusterfs

6.1 StorageClass動態存儲


kubernetes共享存儲provider模式：

靜態模式(Static)：集群管理員手工創建PV，在定義PV時設置後端存儲的特性；

動態模式(Dynamic)：集群管理員不需要手工創建PV，而是通過StorageClass的設置對後端存儲進行描述，標記為某種”類型(Class)”；此時要求PVC對存儲的類型進行說明，系統將自動完成PV的創建及與PVC的綁定；PVC可以聲明Class為””，說明PVC禁止使用動態模式。

基於StorageClass的動態存儲供應整體過程如下圖所示：


  1. 集群管理員預先創建存儲類（StorageClass）；

  2. 用戶創建使用存儲類的持久化存儲聲明(PVC：PersistentVolumeClaim)；

  3. 存儲持久化聲明通知系統，它需要一個持久化存儲(PV: PersistentVolume)；

  4. 系統讀取存儲類的信息；

  5. 系統基於存儲類的信息，在後台自動創建PVC需要的PV；

  6. 用戶創建一個使用PVC的Pod；

  7. Pod中的應用通過PVC進行數據的持久化；

  8. 而PVC使用PV進行數據的最終持久化處理。


提示：關於Kubernetes的部署參考《附003.Kubeadm部署Kubernetes》。

6.2 定義StorageClass


關鍵字說明：

  • provisioner：表示存儲分配器，需要根據後端存儲的不同而變更；

  • reclaimPolicy: 默認即”Delete”，刪除pvc后，相應的pv及後端的volume，brick(lvm)等一起刪除；設置為”Retain”時則保留數據，若需刪除則需要手工處理；

  • resturl：heketi API服務提供的url；

  • restauthenabled：可選參數，默認值為”false”，heketi服務開啟認證時必須設置為”true”；

  • restuser：可選參數，開啟認證時設置相應用戶名；

  • secretNamespace：可選參數，開啟認證時可以設置為使用持久化存儲的namespace；

  • secretName：可選參數，開啟認證時，需要將heketi服務的認證密碼保存在secret資源中；

  • clusterid：可選參數，指定集群id，也可以是1個clusterid列表，格式為”id1,id2”；

  • volumetype：可選參數，設置卷類型及其參數，如果未分配卷類型，則有分配器決定卷類型；如”volumetype: replicate:3”表示3副本的replicate卷，”volumetype: disperse:4:2”表示disperse卷，其中‘4’是數據，’2’是冗餘校驗，”volumetype: none”表示distribute卷


提示：關於glusterfs各種不同類型的卷見《004.RHGS-創建volume》。

  1 [root@k8smaster01 ~]# echo -n "admin123" | base64		#將密碼轉換為64位編碼
  2 YWRtaW4xMjM=
  3 [root@k8smaster01 ~]# mkdir -p heketi
  4 [root@k8smaster01 ~]# cd heketi/
  5 [root@k8smaster01 ~]# vi heketi-secret.yaml			#創建用於保存密碼的secret
  6 apiVersion: v1
  7 kind: Secret
  8 metadata:
  9   name: heketi-secret
 10   namespace: heketi
 11 data:
 12   # base64 encoded password. E.g.: echo -n "mypassword" | base64
 13   key: YWRtaW4xMjM=
 14 type: kubernetes.io/glusterfs
 15 [root@k8smaster01 heketi]# kubectl create -f heketi-secret.yaml	#創建heketi
 16 [root@k8smaster01 heketi]# kubectl get secrets -n heketi
 17 NAME                                 TYPE                                  DATA   AGE
 18 default-token-6n746                  kubernetes.io/service-account-token   3      144m
 19 heketi-config-secret                 Opaque                                3      142m
 20 heketi-secret                        kubernetes.io/glusterfs               1      3m1s
 21 heketi-service-account-token-ljlkb   kubernetes.io/service-account-token   3      143m
 22 [root@kubenode1 heketi]# vim gluster-heketi-storageclass.yaml	#正式創建StorageClass
 23 apiVersion: storage.k8s.io/v1
 24 kind: StorageClass
 25 metadata:
 26   name: gluster-heketi-storageclass
 27 parameters:
 28   resturl: "http://10.254.111.219:8080"
 29   clusterid: "67004a06fbcb4fa525bcec1fbaa9ef2d"
 30   restauthenabled: "true"					#若heketi開啟認證此處也必須開啟auth認證
 31   restuser: "admin"
 32   secretName: "heketi-secret"					#name/namespace與secret資源中定義一致
 33   secretNamespace: "heketi"
 34   volumetype: "replicate:3"
 35 provisioner: kubernetes.io/glusterfs
 36 reclaimPolicy: Delete
 37 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-storageclass.yaml



注意：storageclass資源創建后不可變更，如修改只能刪除后重建。

  1 [root@k8smaster01 heketi]# kubectl get storageclasses		#查看確認
  2 NAME                          PROVISIONER               AGE
  3 gluster-heketi-storageclass   kubernetes.io/glusterfs   85s
  4 [root@k8smaster01 heketi]# kubectl describe storageclasses gluster-heketi-storageclass




6.3 定義PVC

  1 [root@k8smaster01 heketi]# vi gluster-heketi-pvc.yaml
  2 apiVersion: v1
  3 kind: PersistentVolumeClaim
  4 metadata:
  5   name: gluster-heketi-pvc
  6   annotations:
  7     volume.beta.kubernetes.io/storage-class: gluster-heketi-storageclass
  8 spec:
  9   accessModes:
 10   - ReadWriteOnce
 11   resources:
 12     requests:
 13       storage: 1Gi


注意：accessModes可有如下簡寫：

  • ReadWriteOnce：簡寫RWO，讀寫權限，且只能被單個node掛載；

  • ReadOnlyMany：簡寫ROX，只讀權限，允許被多個node掛載；

  • ReadWriteMany：簡寫RWX，讀寫權限，允許被多個node掛載。


  1 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-pvc.yaml -n heketi
  2 [root@k8smaster01 heketi]# kubectl get pvc -n heketi
  3 [root@k8smaster01 heketi]# kubectl describe pvc gluster-heketi-pvc -n heketi
  4 [root@k8smaster01 heketi]# kubectl get pv -n heketi
  5 [root@k8smaster01 heketi]# kubectl describe pv pvc-ca949559-094a-11ea-8b3c-000c29fa7a79 -n heketi




  1 [root@k8smaster01 heketi]# kubectl describe endpoints glusterfs-dynamic-ca949559-094a-11ea-8b3c-000c29fa7a79 -n heketi




提示：由上可知：PVC狀態為Bound，Capacity為1G。查看PV詳細信息，除容量，引用storageclass信息，狀態，回收策略等外，同時可知GlusterFS的Endpoint與path。EndpointsName為固定格式：glusterfs-dynamic-PV_NAME，且endpoints資源中指定了掛載存儲時的具體地址。

6.4 確認查看


通過5.3所創建的信息：

  • volume與brick已經創建；

  • 主掛載點（通信）在172.24.8.41節點，其餘兩個節點備選；

  • 三副本的情況下，所有節點都會創建brick。

  1 [root@k8smaster01 ~]# kubectl get pod -n heketi
  2 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- lsblk	#glusterfs節點查看
  3 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- df -hT	#glusterfs節點查看
  4 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- gluster volume list
  5 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- gluster volume info vol_29ba6f9665522ad5893412e61799a433				#glusterfs節點查看




6.5 Pod掛載測試

  1 [root@xxx ~]# yum -y install centos-release-gluster
  2 [root@xxx ~]# yum -y install glusterfs-fuse					#安裝glusterfs-fuse



提示：本環境master節點也允許分發pod，因此所有master也必須安裝glusterfs-fuse以便於正常掛載，同時版本需要和glusterfs節點一致。

  1 [root@k8smaster01 heketi]# vi gluster-heketi-pod.yaml
  2 kind: Pod
  3 apiVersion: v1
  4 metadata:
  5   name: gluster-heketi-pod
  6 spec:
  7   containers:
  8   - name: gluster-heketi-container
  9     image: busybox
 10     command:
 11     - sleep
 12     - "3600"
 13     volumeMounts:
 14     - name: gluster-heketi-volume			#必須和volumes中name一致
 15       mountPath: "/pv-data"
 16       readOnly: false
 17   volumes:
 18   - name: gluster-heketi-volume
 19     persistentVolumeClaim:
 20       claimName: gluster-heketi-pvc	  	 	#必須和5.3創建的PVC中的name一致
 21 [root@k8smaster01 heketi]# kubectl create -f gluster-heketi-pod.yaml -n heketi	#創建Pod


6.6 確認驗證

  1 [root@k8smaster01 ~]# kubectl get pod -n heketi | grep gluster-heketi
  2 gluster-heketi-pod        1/1     Running   0          4m58s
  3 [root@k8smaster01 ~]# kubectl exec -it gluster-heketi-pod /bin/sh -n heketi 	#進入Pod寫入測試文件
  4 / # cd /pv-data/
  5 /pv-data # echo "This is a file!" >> a.txt
  6 /pv-data # echo "This is b file!" >> b.txt
  7 /pv-data # ls
  8 a.txt  b.txt
  9 [root@k8smaster01 ~]# kubectl exec -it gluster-heketi-pod -n heketi -- df -h	#查看所掛載的glusterfs



  1 [root@k8smaster01 ~]# kubectl get pods -n heketi -o wide		#查看對應的glusterfs node



  1 [root@k8smaster01 ~]# kubectl exec -ti glusterfs-b854k -n heketi -- cat /var/lib/heketi/mounts/vg_2c7a02d1b1b7c1f165283b6691062102/brick_16e37a18a5e5fd40e14338ba78d99565/brick/a.txt
  2 This is a file!



提示：通過Pod寫入相應的測試文件，然後通過glusterfs node節點查看是否存在。

6.7 刪除資源

  1 [root@k8smaster01 ~]# cd heketi/
  2 [root@k8smaster01 heketi]# kubectl delete -f gluster-heketi-pod.yaml -n heketi
  3 [root@k8smaster01 heketi]# kubectl delete -f gluster-heketi-pvc.yaml
  4 [root@k8smaster01 heketi]# kubectl get pvc -n heketi
  5 [root@k8smaster01 heketi]# kubectl get pv -n heketi
  6 [root@k8smaster01 heketi]# kubectl exec -ti glusterfs-b854k -n heketi gluster volume list | grep gluster




參考：https://www.linuxba.com/archives/8152

https://www.cnblogs.com/blackmood/p/11389811.html本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

ef+Npoi導出百萬行excel之踩坑記

admin

        最近在做一個需求是導出較大的excel，本文是記錄我在做需求過程中遇到的幾個問題和解題方法，給大家分享一下，一來可以幫助同樣遇到問題的朋友，二呢，各位大神也許有更好的方法可以指點小弟一下，讓我順便學習一下。 背景：：工頭：“小鍾啊，xx界面加個導出excel功能03以後的格式，需要能支持到excel的最大行，同時需要5個併發就行” 我：“收到，但是數據大的時候速度可能比較慢。” 工頭：“你先做後續客戶反饋了在給他加進度條。” Npoi神器介紹：SXSSFWorkbook 專門用來導出大數據用，他會把數據先寫入C盤的臨時目錄；不會所有 都留在內存里；更詳細介紹請百度或者參考（ ） 有了這層基礎開始劈里啪啦一段操作寫代碼；（以下代碼非生產代碼只是我為了帖子寫重現問題的測試代碼） 首先開個線程模擬併發 編寫導出方法：記錄時間、創建SXSSFWorkbook 代碼如圖： 啟動運行； 好！第一口鍋已造好，看這個提示，前面說了SXSSFWorkbook 是會先把緩存數據寫入Windows臨時文件裡頭的，這個目錄正好是Windows的臨時文件夾雖然是個錯誤但是驗證了剛剛的說法；至於這個錯誤看提示 我們有個大膽的想法是文件佔用問題，應該是創建文件的時候文件已經存在了，這樣我們把npoi的dll打開來看看，通過看源碼和各種f12我們看到了這麼一段代碼 這裏看到用來隨機數，而我們知道net的隨機數在極短的時間內生成是不可靠的（詳見百度或者： ）也就是說生成一樣的文件名，然後我們在通過 github里可以看到   早在年初NPOI就對這個問題做了更改就換成guid了，隨後我來到了nuget nuget最新版 是去年12月份發布，並沒有包含上面的更改； 所以呢 要麼github下載最新版編譯要麼自己解決，想了想如果換版本的話以前的功能可能會影響到所以，我們就在外面加一把小鎖吧！如圖   這樣呢我們在試試！   很好 不會在出現文件佔用問題了；好繼續導出！ 既然是都先寫入緩存文件是不是佔用的內存就很小了 來看看 2G多。。。什麼情況，還在漲   3G。。。這明顯不符合工頭的需求了，然後終於它炸了 第一念頭是為啥我該怎麼辦，設置GC的回收模式？手動多GC？還是要把代碼給拿下來看看，看看這麼大內存哪裡沒釋放文件？冷靜、冷靜、想想，既然是內存爆了 那麼正確流程應該是抓取看看是什麼吃的內存得出結果再去改東西， 發現了啥是不是很熟悉的東西？ 狀態管理、包裝類，想到了啥 EF的“模型跟蹤”這個功能佔用的內存最大了。那就去掉吧 加上這麼一句 意思是無跟蹤查詢 ，修改實例后SaveChanges不對對它生效； （AsNoTracking 更詳情理解介紹請百度在加上msdn： ） 現在在繼續導出看看： 內存是吃的不大了， 可以看出臨時文件還是很大的，這還沒導完呢，所以做的時候 盡量要保證下硬盤的空間！ 等待。。。 總結： 1.導出大數據用SXSSFWorkbook 2.構建SXSSFWorkbook 時候lock或者自己編譯最新版本 3.我們做導出時，ef查詢數據後記得加AsNoTracking 關閉綁定跟蹤。（以後日常開發中如果只需要查詢的也可以這樣做） 4.SXSSFWorkbook 導出大數據 臨時文件夾所在的硬盤不能太小 因為會生成大於excel本身的緩存文件！     最後導出完畢 用時：  本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

Gogoro 與小牛歐洲廝殺，搶佔德國灘頭堡

admin

德國因為天氣較冷，摩托車被視為是夏天的玩具，但現在卻成為Gogoro 與中國牛電科技等亞洲電動機車品牌進軍歐洲市場的敲門磚。

現在電動機車可以透過應用程式連結到智慧手機，進行簡易的充電、里程控制以及反偷竊與帳單功能等等。日經新聞報導，Gogoro 去年8 月開始在德國柏林透過電動機車分享計畫Coup 來布局市場，起初提供200 台，近期會再增加800 台，而中國的牛電科技則在全德國、奧利地、比利時與瑞士市場開始銷售，尚未公布銷售數字。

這兩家競爭者都與德國汽車零件供應商Bosch 合作，Coup 是Bosch 的子公司，而牛電科技電動機車則使用Bosch 的引擎。Bosch 也積極與電動車廠合作，作為從內燃機引擎轉向電動車引擎世代的契機，因為電動機車只需要數十個零件，而傳統機車需要上千個零件，德國許多汽車零件供應商都預告裁員。Coup 則是Bosch 成立來形塑城市移動趨勢的前哨戰，以提供用戶服務為核心。

報導指出，Gogoro 的電池充電概念讓Coup 印象深刻。Gogoro 自2015 年以來一直在台灣城市營運自己的電子移動計畫，但客戶必須購買相當於6 萬元新台幣的電動機車，然後在交換站網路交換電池，每月付款新台幣300~900 元。Gogoro 在柏林則提供全天出租20 歐元，或3 歐元30 分鐘，而不需要購買一台電動機車。

Coup 智慧手機應用程式可顯示客戶在哪裡可以找到可用的電動機車、解鎖和鎖定，並進行計費。在使用過程中，應用程式會顯示電動機車的位置，並通知電池狀態和剩餘里程。總距離約95 公里，最高時速45 公里，21 歲以上的人可以使用德國駕駛執照租用。

Gogoro 表示，選擇柏林而不是冬天仍溫暖怡人的羅馬與馬德里，是因為這裡能引領潮流，而且柏林人民擁抱新事物。1980 年柏林以自己的共享資本為傲，引進Airbnb 的前身Mitwohnzentralen，並在2014 年推出一個電動鑽機租借商店。這座城市擁有十幾個汽車共享計畫。分析師認為選擇德國也是利用德國公司高品質的聲譽來進軍其他歐洲市場。

中國牛電科技推出的電動機車售價2,700 歐元，也使用與Coup 類似的應用程式，趁Gogoro 專注布局柏林時快速佔領其他市場。在德國城鎮Fulda，三菱與鈴木汽車的經銷商自3 月來開始銷售小牛電動機車。

Coup 即將進軍巴黎，提供首批600 台Gogoro，讓Gogoro 在歐洲銷售量達到1,600 台，另外在台灣銷售2 萬台。牛電科技預計到2018 年全球賣出15 萬台。截至2016 年9 月，中國已經賣出10 萬台。

（合作媒體：。圖片出處：Gogoro）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

特斯拉大眾電動車Model 3本周量產，預估月底交車

admin

特斯拉周一公佈第二季僅交車2.2萬輛，上半年合計4.7萬輛，僅以最低標達陣。不過這不打緊，市場最關注的是特斯拉執行長馬斯克（Elon Musk）隨後宣布大眾化電動車Model 3本周五即可進入量產，比預估時程提前兩周。

特斯拉說電池模組供給嚴重不足，導致產出受限，直至六月才獲得抒解，預期Model S與Model X等高檔車下半年交車狀況有望優於上半年。特斯拉原預期上半年交車量介於4.7-5萬輛之間。（路透社）

特斯拉目前已收到近40萬輛Model 3的預購訂單，據馬斯克表示，首批30輛Model 3將在7月28日交車，九月產能可提升至1500輛，估計十二月可達成月產2萬輛的目標。

市場研究機構Consumer Edge Research分析師艾伯汀（James Albertine）指出，按照特斯拉現在的規劃，Model 3進度微幅超前，不然至少也在預期之內，證明馬斯克之前的豪語不是隨便說說。（金融時報）

特斯拉股價周一於正常交易時段收跌2.49%，但今年迄今累計漲幅仍高達65%，市值來到580億美元。

（本文內容由授權使用。圖片出處：Tesla）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

圖解Elasticsearch的核心概念

admin

本文講解大綱，分8個核心概念講解說明：

  • NRT
  • Cluster
  • Node
  • Document&Field
  • Index
  • Type
  • Shard
  • Replica

Near Realtime（NRT）近實時

Elasticsearch的核心優勢就是（Near Real Time NRT）近乎實時，我們稱之為近實時。
NRT有兩個意思，下面舉例說明下：

  • 從寫入索引數據到數據可以被搜索到有一個小延遲（大概1秒）；

舉個例子：電商平台新上架一個新商品，1秒後用戶就可搜索到這個商品信息，這就是近實時。

  • 基於Elasticsearch執行搜索和分析可以達到秒級查詢

也舉個例子說明，比如我現在想查詢我在淘寶，最近一年都買過幾件商品，總共花了多少錢，最貴的商品多少錢，哪個月買到東西最多，什麼類型的商品買的最多這樣的信息，如果淘寶說，你要等待10分鐘才能出結果，你是不是很崩潰，這個延遲的時間就不是近實時，如果淘寶可以秒級別返回給你，就是近實時了。

下面畫一個圖，解釋下三個基本概念的

Cluster：集群

包含多個節點，每個節點屬於哪個集群是通過一個配置（集群名稱，默認是elasticsearch）來決定的，對於中小型應用來說，剛開始一個集群就一個節點很正常。集群的目的為了提供高可用和海量數據的存儲以及更快的跨節點查詢能力。

Node：節點

集群中的一個節點，節點也有一個名稱（默認是隨機分配的），節點名稱很重要（在執行運維管理操作的時候），默認節點會去加入一個名稱為“elasticsearch”的集群，如果直接啟動一堆節點，那麼它們會自動組成一個elasticsearch集群，當然一個節點也可以組成一個elasticsearch集群

Document&field：文檔和字段

document 是es中的最小數據單元，一個document可以是一條客戶數據，一條商品分類數據，一條訂單數據，通常用JSON數據結構表示，每個index下的type中，都可以去存儲多個document。一個document裏面有多個field，每個field就是一個數據字段。

相當於mysql里的行，可以簡單這麼理解，舉個例子。一個商品的文檔數據一條如下：

product document
{
  "product_id": "1000",
  "product_name": "mac pro 2019 款筆記本",
  "product_desc": "高性能，高分辨率，編程必備神器",
  "category_id": "2",
  "category_name": "电子產品"
}

Index：索引

包含一堆有相似結構的文檔數據，比如可以有一個客戶索引，商品分類索引，訂單索引，索引有一個名稱。
一個index包含很多document，一個index就代表了一類類似的或者相同的document。比如說建立一個product index，商品索引，裏面可能就存放了所有的商品數據，所有的商品document。

Type：類型

每個索引里都可以有一個或多個type，type是index中的一個邏輯數據分類，一個type下的document，都有相同的field，比如博客系統，有一個索引，可以定義用戶數據type，博客數據type，評論數據type。

商品index，裏面存放了所有的商品數據，商品document

但是商品分很多種類，每個種類的document的field可能不太一樣，比如說電器商品，可能還包含一些諸如售後時間範圍這樣的特殊field；生鮮商品，還包含一些諸如生鮮保質期之類的特殊field

type，日化商品type，電器商品type，生鮮商品type

日化商品type：product_id，product_name，product_desc，category_id，category_name
電器商品type：product_id，product_name，product_desc，category_id，category_name，service_period
生鮮商品type：product_id，product_name，product_desc，category_id，category_name，eat_period

每一個type裏面，都會包含一堆document

{
“product_id”: “2”,
“product_name”: “長虹電視機”,
“product_desc”: “4k高清”,
“category_id”: “3”,
“category_name”: “電器”,
“service_period”: “1年”
}

{
“product_id”: “3”,
“product_name”: “基圍蝦”,
“product_desc”: “純天然，冰島產”,
“category_id”: “4”,
“category_name”: “生鮮”,
“eat_period”: “7天”
}

Shard 分片，也稱 Primary Shard

單台機器無法存儲大量數據，es可以將一個索引中的數據切分為多個shard，分佈在多台服務器上存儲。有了shard就可以橫向擴展，存儲更多數據，讓搜索和分析等操作分佈到多台服務器上去執行，提升吞吐量和性能。

每個shard都是一個lucene index。

Replica 副本,也稱 Replica Shard

任何一個服務器隨時可能故障或宕機，此時shard可能就會丟失，因此可以為每個shard創建多個replica副本。replica可以在shard故障時提供備用服務，保證數據不丟失，多個replica還可以提升搜索操作的吞吐量和性能。

primary shard（建立索引時一次設置，不能修改，默認5個），

replica shard（隨時修改數量，默認1個），

默認每個索引10個shard，5個primary shard，5個replica shard，最小的高可用配置，是2台服務器。

相關索引解釋說明：

  • index包含多個shard
  • 每個shard都是一個最小工作單元，承載部分數據，lucene實例，完整的建立索引和處理請求的能力
  • 增減節點時，shard會自動在nodes中負載均衡
  • primary shard和replica shard，每個document肯定只存在於某一個primary shard以及其對應的replica shard中，不可能存在於多個primary shard
  • replica shard是primary shard的副本，負責容錯，以及承擔讀請求負載
  • primary shard的數量在創建索引的時候就固定了，replica shard的數量可以隨時修改
  • primary shard的默認數量是5，replica默認是1，默認有10個shard，5個primary shard，5個replica shard
  • primary shard不能和自己的replica shard放在同一個節點上（否則節點宕機，primary shard和副本都丟失，起不到容錯的作用），但是可以和其他primary shard的replica shard放在同一個節點上

索引在集群中分配圖：

本文由博客一文多發平台 發布！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

WeTest明星工具-移動端性能測試PerfDog初探

admin

在十一月初，騰訊就官宣了一則消息，騰訊WeTest明星工具-PerfDog面向全球發布。官宣介紹如下：。我在看到該新聞時，有種大開眼界的感覺，移動端的性能測試原來可以這麼簡單。今天閑暇之餘，來了一波初探，簡單體驗了一番。

軟件性能數據採集

我們先來了解下通過該工具能採集到哪些性能數據：

PerfDog支持移動平台所有應用程序（遊戲、APP應用、瀏覽器、小程序等）及Android模擬器，桌面應用程序PerfDog支持在Windows和Mac機器使用運行。在iOS和Android平台獲取性能參數如下：

iOS平台 （與蘋果官方Xcode工具參數對齊一致）

  • Screenshot
  • FPS(1秒內遊戲畫面或者應用界面真實平均刷新次數，俗稱幀率/FPS)
       1) Avg(FPS):平均幀率(一段時間內平均FPS)
       2) Var(FPS):幀率方差(一段時間內FPS方差)
       3) Drop(FPS):降幀次數(平均每小時相鄰兩個FPS點下降大於8幀的次數)
  • Jank(1s內卡頓次數。iOS9.1以下系統暫時不支持。類似Android的Jank卡頓和iOS的FramePacing平滑度統計原理。幀率FPS高並不能反映流暢或不卡頓。比如：FPS為50幀，前200ms渲染一幀，后800ms渲染49幀，雖然幀率50，但依然覺得非常卡頓。同時幀率FPS低，並不代表卡頓，比如無卡頓時均勻FPS為15幀。所以，平均幀率FPS與卡頓無任何直接關係)
        PerfDog計算方法：同時滿足兩條件，則認為是一次卡頓Jank.
        1、 當前幀耗時>前三幀平均耗時2倍。
        2、 當前幀耗時>兩幀電影幀耗時(1000ms/24*2=84ms)。
        同時滿足兩條件，則認為是一次嚴重卡頓BigJank.
        1、 當前幀耗時>前三幀平均耗時2倍。
        2、 當前幀耗時>三幀電影幀耗時(1000ms/24*3=125ms)。
    計算思路：考慮視覺慣性，假設以前三幀的平均幀耗時為參考，作為vsync時間間隔，連續兩次vsync沒有新渲染畫面刷新，則認為是一次潛在卡頓，也就是說下一幀耗時大於前三幀平均幀耗時2倍，則認為一次潛在卡頓。同時單幀耗時滿足大於兩倍電影幀耗時1000ms/24*2 (由於人眼低於24幀才能辨別畫面不連續性)，則認為是一次真正卡頓。同時若單幀耗時大於3倍電影幀耗時，則認為是一次嚴重卡頓。
    註解：為什麼是兩次vsync？GPU一般是3重緩衝buffer，當前幀已佔用一個buffer，即剩餘2緩衝buffer，人眼一般可容忍2幀延遲。 為什麼是兩幀電影幀耗時？低於24幀畫面，人眼就能感知到畫面不連續性，電影一般都是24幀。即電影幀耗時1000ms/24=41.67ms，兩幀電影幀耗時也就是41.67ms*2，三幀電影幀耗時是41.67ms*3。
       1) BigJank:1s內頓嚴重卡次數
       2) Jank(/10min):平均每10分鐘卡頓次數。
       3) BigJank(/10min):平均每10分鐘嚴重卡頓次數
  • FTime(上下幀畫面显示時間間隔，即認為幀耗時，iOS9.1以下系統暫時不支持。)
       1) Avg(FTime):平均幀耗時 
       2) Delta(FTime):增量耗時(平均每小時兩幀之間時間差>100ms的次數)
  • CPU Usage(Total整機/App進程，統計結果合Xcode一致)
  • Memory (是統計FootPrint，注：OOM與FootPrint有關，與系統、機型無關。只與RAM有關，如1G內存機器。FootPrint超過650MB，引發OOM）。受iOS平台限制，暫時無法獲取ios10及以下系統的memory。後續版本增加。如做性能測試，建議升級iOS系統版本
  • Xcode Memory (XCode Debug Gauges統計方式即XCode Memory）。受iOS平台限制，暫時無法獲取ios10及以下系統的Xcode Memory。後續版本增加。如做性能測試，建議升級iOS系統版本
  • Real Memory(Xcode Instrument統計方式即Real Memory，實際佔用物理內存。注：物理內存與系統策略有關，關注意義不大)
  • Virtual Memory(虛擬內存)
  • Wakeups(線程喚醒次數)。注：超過150進程很大可能會被系統kill
  • CSwitch(上下文切換測試)。注：單核超過14000進程會被系統Kill
  • GPU Utilization(Render/Tilter/Device）
       1) Render：渲染器利用率(像素着色處理階段，若佔比高，說明是PS階段出現瓶頸，shader過於複雜或紋理大小、採樣複雜等) 
       2) Tilter:Tilter利用率(頂點着色處理階段，若佔比高，說明是VS階段出現瓶頸，頂點數太多等原因)
       3) Device:設備利用率(整體GPU利用率)
  • Network(Recv/Send，測試目標進程流量，和Xcode結果一致)
  • Battery Power(整機實時Current電流、Voltage電壓、Power功率)（注：和Xcode Instrument結果一致）
  • Log(系統調試日誌信息)

Android平台

  • Screenshot
  • FPS(1秒內遊戲畫面或者應用界面真實平均刷新次數，俗稱幀率/FPS)
       1) Avg(FPS):平均幀率(一段時間內平均FPS)
       2) Var(FPS):幀率方差(一段時間內FPS方差)
       3) Drop(FPS):降幀次數(平均每小時相鄰兩個FPS點下降大於8幀的次數)
  • Jank(1s內卡頓次數。解釋說明如iOS平台說明)
       1) BigJank:1s內嚴重卡頓次數
       2) Jank(/10分鐘):平均每10分鐘卡頓次數
       3) BigJank(/10分鐘):平均每10分鐘嚴重卡頓次數 
  • FTime(上下幀畫面显示時間間隔，即認為幀耗時)
       1) Avg(FTime):平均幀耗時
       2) Delta(FTime):增量耗時(平均每小時兩幀之間時間差>100ms的次數)
  • CPU Usage(Total整機/App目標進程，統計結果和Android Studio Profiler一致)
  • CPU Clock(各個CPU核心的頻率和使用率)
  • Memory (PSS Memory，統計結果和Android Java API標準結果一致，與Meminfo也一致。注：部分三星機器系統修改了Meminfo底層統計方式，導致Meminfo與Java AP統計結果不一致，新出三星機器已修復)
  • Swap Memory (Swap Memory)
  • Virtual Memory
  • Memory Detail(NativePSS、GFX、GL、Unknown)
  • GPU Usage(目前僅支持高通芯片手機)
  • GPU Frequency(目前僅支持高通芯片手機)
  • Network(Recv/Send)
  • CTemp(CPU溫度)
  • Battery Power(Current電流、Voltage電壓、Power功率)（注：與儀器測試誤差<3%左右）
  • Log(系統調試日誌信息)

上述內容來自官網使用文檔。我們了解了參數，就實際來操作一下吧。對於工具的介紹，網絡上都有，我就結合自己的實際體驗來說吧。

使用的基本流程

在自己實踐使用時，基本流程如下：

1.註冊賬號（只有註冊賬號后才能下載安裝包）

2.下載安裝包並解壓

3.在perfdog後台創建測試項目

4.打開可執行文件PerfDog.exe

5.使用註冊的賬號登錄

6.使用usb將手機和電腦連接（不能鎖屏，開啟調試模式）

7.選擇連接模式（wifi還是usb）

8.選擇app應用列表

9.配置要監控的數據

10.開始記錄數據

11.操作對應app

12.停止記錄數據（不能少於10S）

13.上傳記錄數據

14.進入perfdog後台查看性能數據

流程介紹

前五步操作就不講述了，大家都懂。我們直接從第六步說起，我使用的是ios設備。

連接設備

iOS： 則即插即用，用戶無需做任何操作。

Android： 有兩種模式，非安裝模式和安裝模式。

  • a. 非安裝模式：

    手機即插即用，無需任何設置及安裝，使用非常簡單，但手機屏幕上沒有實時性能數據显示。

  • b. 安裝模式：

    需要在手機上自動安裝PerfDog.apk，手機屏幕上有實時性能數據显示。（請開啟Debug調試模式、允許USB安裝和PerfDog懸浮窗管理權限），啟動PC版PerfDog.exe，則會在手機上自動PUSH安裝PerfDog.apk，具體安裝類似各個手機廠商安裝第三方APP提示安裝即可。（注：由於很多手機安裝需要賬號密碼，導致無法自動安裝，如果自動安裝失敗，則會把安裝文件PerfDog.apk釋放到當前文件夾里，手動安裝PerfDog.apk即可）。

這裏重點說明下Android平台下，LMK和Swap這兩個參數意義：

LMK：Android平台下OOM與遊戲進程內存大小無關，主要是系統剩餘物理內存有關。系統剩餘物理內存小於LMK，則會引起OOM。

Swap： 系統進程用到zram/vnswap內存壓縮技術。不同手機系統啟用Swap memeroy大小不同。

測試模式

通過usb連接電腦後，出現如下界面，可以選擇測試模式：

USB模式測試：

　　USB連線，在設備列表選擇USB圖標設備進行USB模式測試(插線模式測試功率無任何意義)。

WIFI模式測試(測試功率)：

　　USB連線后，在設備列表選擇WIFI圖標設備進行WIFI模式測試。WIFI檢測連接成功后，拔掉USB連接線。（注：需要PC和被測手機連接同一WIFI，WIFI檢測連接成功后，拔掉被測手機USB線(插線模式測試功率無任何意義)）。

在實踐中，USB和WiFi模式我都有使用。選擇模式后，界面會展示設備的詳細信息，如下：

選擇測試應用

選擇模式后，則可以選擇要測試的應用了（當前手機中的所有app都可以被選擇），如下頁面：

選擇對應被測應用，並操作對應的app，界面展示如下：

注意點：Android平台，安裝模式下，手機屏幕左上角有實時性能數據显示（Android手機請打開PerfDog懸浮窗管理權限，否則手機上不會显示性能參數）。

開啟懸浮權限

android設備中的界面性能參數显示如下：

功能介紹

1.性能參數配置

性能參數可在界面中配置，點擊界面中的+號即可，如下：

①點擊對應條目參數，顏色會變深，圖表數據則會展示在界面中

②勾選對應條目參數，表示需要收集該數據

2.記錄保存

點擊右側的藍色開始按鈕，則表示在記錄數據，如下：

需要注意的是：記錄時間不能少於10S。少於10S，則會提示如下信息：

點擊按鈕后，記錄會停止記錄並保存數據，如下：

2.1 提交記錄到perfdog後台

可以修改名稱，點擊confirm，數據會上傳到perfdog的後台，如下：

可以查看詳細的性能數據，如下所示：

2.2 記錄保存到本地

勾選保存按鈕，數據就會保存到本地，如下：

可以打開excel文件查看對應的性能數據：

3.數據回放

點擊perfdog界面上的文件夾按鈕，選擇對應的本地數據，即可以回放記錄，操作如下：

可在界面查看回放結果，如下：

4.批註及標定

雙擊鼠標左鍵，增加批註，再次雙擊，則取消批註。

單擊鼠標左鍵，則增加標定，再次點擊則重新標定。

增加了批註和標定的界面如下所示，紅色為批註，淡紫色為標定：

5.性能參數分析

5.1 數據統計

可以選擇一個時間段內的數據，進行統計，如下：

5.2 設置性能參數統計分析閾值

在perfdog界面中的setting下，可以配置，如下：

5.3 保存框選數據

對某一時間段內的數據框選后，可以單獨保存片段，在框選範圍內，右鍵即可，如下：

6.場景標籤

通過標籤按鈕給性能數據打標籤，鼠標左鍵雙擊顏色區域可修改對應區域標籤名

7.日誌記錄

在perfdog界面，可以查看對應日誌，也可以設置查看日誌的等級，如下：

在嘗試WIFI模式時，發現log按鈕勾選不了。

8.停止功能

停止測試應用，不需要拔掉數據線，或者斷開連接，在選擇應用的界面中，選擇NULL即可，如下：

9.截圖錄屏

連接安卓設備，並使用安裝模式，可配置截屏參數，如下：

界面就會記錄操作的過程，如下所示：

如此記錄是不是很明了？但這種用法會影響性能參數，實際用途中不推薦。如果覺得新鮮，可以嘗試使用即可。

PerfDog後台使用

1.邀請人員

可以邀請對應人員一起維護測試項目

2.數據共享

數據共享后，可以在任務數據中查看明細，可按android、ios區分，以及app包的版本，設備版本來查看。

使用注意點

1.設備連接

iOS： 若PerfDog檢測不到連接手機或無法測試，請先安裝確保最新iTunes是否能連上手機。

Android： 請開啟手機Debug調試模式及允許USB安裝。

2.截圖記錄影響性能

截屏記錄影響性能(整體FPS影響<=1。小米5:CPU=1%左右。IPhone7P:CPU<2%)，若無需請不要開啟截屏。

總結

使用PerfDog工具下來，整體有以下幾點感受。

1.對性能指標的測試，更加便捷；

2.易操作

3.記錄支持回放

4.數據便於管理與查看

PerfDog工具是款不錯的性能測試工具，點贊一波。

最後，附上官方的操作手冊：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

PL真有意思（二）：程序設計語言語法

admin

前言

雖然標題是程序語言的語法，但是講的是對詞法和語法的解析，其實關於這個前面那個寫編譯器系列的描述會更清楚，有關語言語法的部分應該是穿插在整個設計當中的，也看語言設計者的心情了

和英語漢語這些自然語言不一樣，計算機語言必須是精確的，它們的語法和語義都必須保證沒有歧義，這當然也讓語法分析更加簡單

所以對於編譯器一項很重要的任務就是時別程序設計語言的結構規則，要完成這個目標就需要兩個要求：

  • 完成對語法規則的描述
  • 確定給定程序是否按照這些規則構造起來，也就是符合語法規則

第一個要求主要由正則表達式和上下文無關文法來描述完成，而第二個要求就是由編譯器來完成，也就是語法分析了

描述語法：正則表達式和上下文無關語法

對於詞法，都可以用三種規則描述出來：

  1. 拼接
  2. 選擇
  3. Kleene（也就是重複任意多次）

比如一個整數常量就可以是多個数字重複任意多次，也叫做正則語言。如果對於一個字符串，我們再加入遞歸定義即可以描述整個語法，就可以稱作上下文無關語法

單詞正則表達式

對於程序語言，單詞的類型不外乎關鍵字、標識符、符合和各種類型的常量

對於整數常量就可以用這樣的正則表達式來表示

integer -> digit digit* digit -> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

上下文無關文法

一般正則表達式只適用於描述單詞，因為正則表達式無法描述嵌套結構，一般正則表達式的實現都是用有限狀態自動機，之前用Python實現了一個簡單的也是這樣，但是對於匹配任意深度的嵌套結構就需要有一個任意大的狀態機，顯然不符合。而定義嵌套結構對於描述語法非常有用，所以就有了上下文無關文法

expr := id | number | - expr | ( expr ) | expr or expr

op := + | - | * | /

對於上下文無關文法，每條規則叫做一個產生式，產生式左部的符合稱為非終結符，而右部則是多個終結符或者非終結符，最後所有規則都會推到至終結符上，而終結符就是正則表達式定義的單詞

推導和語法樹

一個正確的上下文無關文法，就可以指導我們如何生成一個合乎語法的終結符串

最簡單的就是從開始符號開始，用這個產生式的右部取代開始符合，再從得到的串選擇一個非終結符繼續進行推導，直到沒有剩下的非終結符，這個過程就像遞歸構造一個樹的過程

expr := expr op expr
     := expr op id
     := expr + id
     := expr op expr + id
     := expr op id + id
     := expr * id + id
     := id * id + id

但是對於給定的上下文語法有可能會推導出不止一顆語法分析樹，我們就說這個上下文語法是存在歧義性的。所以對於上面的上下文無關語法還有更好的文法

掃描

掃描也就是詞法分析，詞法分析完全可以不需要什麼正則表達式、自動機什麼的，徒手擼出來，現在業界為了更好的生成錯誤信息，應該很多也是手工的詞法分析器

手工的詞法分析器，無非就是一直讀入字符，到能判斷出它的token在送入語法分析器

有限狀態自動機

使用有限狀態機的詞法分析一般都是這樣的幾個步驟

  • 給出詞法的正則表達式

  • 將正則表達式轉換為非確定有限自動機（NFA）

其實對於任意的正則表達式都可以用拼接、選擇和Kleene閉包來表示

而同樣的，有限自動機也可以通過這三種方式來表示，圖就不畫了，這個在之前寫Python正則表達式引擎的文章里都畫過了（溜了

  • 將NFA轉換為確定性有限狀態自動機（DFA）

將NFA轉換到DFA可以採用的是子集構造法，主要思想就是，在讀入給定輸入之後所到達的DFA狀態，表示的是原來NFA讀入同樣輸入之後可能澳大的所有狀態

  • 最小化DFA

對於最小化DFA的主要思想是，我們把DFA所有狀態分為兩個等價類，終止態狀態和非終止狀態。然後我們就反覆搜索等價類X和輸入符合c，使得當給定C作為輸入時，X的狀態能轉換到位於k>1個不同等價類中的狀態。之後我們就把X劃分為k個類，使得類中所有轉檯對於C都會轉移到同一個老類的成員。直到無法再按這種方式找到劃分的類時，我們就完成了

這四個步驟在之前的寫的正則表達式引擎中都完成了，在那三篇文章里會更詳細一點

語法分析

一般語法分析器的輸入是token流，而輸出是一顆語法分析樹。其中分析方法一般可以分為自上而下和自下而上兩類，這些類中最重要的兩個分別稱為LL和LR

LL表示從左向右，最左推導，LR表示從左向右，最右推導。這兩類文法都是從左到右的順序讀取輸入，然後語法分析器試圖找出輸入的推導結果

自上而下的方式

一般自上而下的語法分析器比較符合之前的推導方法，從根節點開始像恭弘=叶 恭弘節點反覆的遞歸推導，直到當前的恭弘=叶 恭弘節點都是終結符

  • 遞歸下降

遞歸下降很符合上面說的從根節點出發進行推導，一般用於一些相對簡單一些的語言

read A
read B
sum := A + B
write sum
write sum / 2

比如對於這個程序的遞歸下降，語法分析器一開始調用program函數，在讀入第一個單詞read后，program將調用stmt_list，再接着調用stmt才真正開始匹配read A。以這種方式繼續下去，語法分析器執行路徑將追溯出語法分析樹的從左向右、自上而下的遍歷

  • 表格驅動的LL自上而下

表格驅動的LL是基於一個語法分析表格和一個棧

分析流程是

  1. 初始化一個棧
  2. 將開始符號壓入棧
  3. 彈出棧頂，然後根據棧頂的符號和當前的輸入符號查表
  4. 如果彈出的是非終結符，將會繼續查表來確定下一個壓入棧中的產生式
  5. 如果是終結符將進行匹配

預測集合

從上面可以看出來最重要的就是那個語法分析表格了，語法分析表格其實就是根據當前輸入字符對下一個產生式的預測，這裏就要用到一個概念：預測集合，也就是First和Follow集合。這個在之前寫編譯器系列講的比較詳細，在這裏就不寫了

當然LL語法也會有很多處理不了的文法，所以也才會有其它的語法分析方法

自下而上的方式

在實踐中，自下而上的語法分析都是表格驅動的，這種分析器在一個棧中保存所有部分完成的子樹的根。當它從掃描器中得到一個新的單詞時，就會將這個單詞移入棧。當它發現位於棧頂的若干符號組成一個右部時，它就會將這些符號歸約到對應的左部。

一個自底向上的語法分析過程對應為一個輸入串構造語法分析書的過程，它從恭弘=叶 恭弘子節點開始，通過shift和reduce操作逐漸向上到達根節點

自底向上的語法分析需要一個堆棧來存放解析的符號，例如對於如下語法：

0.  statement -> expr
1.  expr -> expr + factor
2.           | factor
3.  factor ->  ( expr )
4.           | NUM

來解析1+2

stack input
null 1 + 2
NUM + 2 開始讀入一個字符，並把對應的token放入解析堆棧，稱為shift操作
factor + 2 根據語法推導式，factor -> NUM,將NUM出棧，factor入棧，這個操作稱為reduce
expr + 2 這裏繼續做reduce操作，但是由於語法推導式有兩個產生式，所以需要向前看一個符合才能判斷是進行shift還是reduce，也就是語法解析的LA
expr + 2 shift操作
expr + NUM null shift操作
expr + factor null 根據fator的產生式進行reduce
expr null reduce操作
statement null reduce操作

此時規約到開始符號，並且輸入串也為空，代表語法解析成功

有限狀態自動機的構建

0.  s -> e
1.  e -> e + t
2.  e -> t
3.  t -> t * f
4.  t -> f
5.  f -> ( e )
6.  f -> NUM
  • 對起始推導式做閉包操作

先在起始產生式->右邊加上一個.

s -> .e

對.右邊的符號做閉包操作，也就是說如果 . 右邊的符號是一個非終結符，那麼肯定有某個表達式，->左邊是該非終結符，把這些表達式添加進來

s -> . e
e -> . e + t
e -> . t

對新添加進來的推導式反覆重複這個操作，直到所有推導式->右邊是非終結符的那個所在推導式都引入

  • 對引入的產生式進行分區

把 . 右邊擁有相同非終結符的表達式划入一個分區，比如

e -> t .
t -> t . * f

就作為同一個分區。最後把每個分區中的表達式中的 . 右移動一位，形成新的狀態節點

  • 對所有分區節點構建跳轉關係

根據每個節點 . 左邊的符號來判斷輸入什麼字符來跳入該節點

比如， . 左邊的符號是 t, 所以當狀態機處於狀態0時，輸入時 t 時， 跳轉到狀態1。

  • 對所有新生成的節點重複構建

最後對每個新生成的節點進行重複的構建，直到完成所有所有的狀態節點的構建和跳轉

小結

這一篇主要是提了對詞法和語法的分析過程，因為想要結合語言設計和實踐，更詳細的應該去看前面的寫一個編譯器系列

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

SpringBoot系列之切換log4j日誌框架

admin

SpringBoot系列之使用切換log4j日誌框架

ok，在pom文件右鍵->Diagrams->show Dependencies….，如圖，找到spring-boot-starter-logging，可以看到SpringBoot的日誌實現默認依賴與logback，ok，如果你對這些知識不是很理解的，建議先看我Springboot專欄的日誌系列博客：

本博客要實現的是切換默認日誌框架為log4j，當然是不建議這樣做的，因為log4j有性能問題，所以其作者才開發了logback，不過作為學習的話，還是可以學一下怎麼切換Springboot默認的日誌框架

先去拿一張圖：圖示，切換日誌框架，為了避免衝突，一般都是先排除日誌框架的實現jar，然後再將之前博客提到的偷梁換柱jar，比如log4j-to-slf4j.jar等等先排除，然後再引入對應的日誌實現jar，如圖所示的slf4j-log4j12.jar，因為本博客並非入門教程，所以學習之前請先參考我之前Springboot日誌方面的博客，再來學習

ok，基於slf4j官方提供的知識，我們就可以實踐了，首先選中logback-classic.jar(logback實現jar)、log4j-to-slf4j.jar(將log4j API強制切換回slf4j的偷梁換柱jar)，然後右鍵，選擇exclusion

ok，再次打開pom文件，可以看到idea自動幫我們exclusion一些jar了

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <exclusions>
                <exclusion>
                    <artifactId>logback-classic</artifactId>
                    <groupId>ch.qos.logback</groupId>
                </exclusion>
                <exclusion>
                        <artifactId>log4j-to-slf4j</artifactId>
                    <groupId>org.apache.logging.log4j</groupId>
                </exclusion>
            </exclusions>
        </dependency>

ok，避免日誌衝突，exclusion了logback的實現jar和偷梁換柱的log4j-to-slf4j之後，我們還需要引入log4j的實現jar

<dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
        </dependency>

ok，這是slf4j官網的說法，但是我發現在一些舊的版本SpringBoot是有提供spring-boot-starter-log4j這個場景啟動器的，所以我們可以更簡便的做log4j引入

直接exclusion spring-boot-starter-logging：

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

然後直接引入log4j的場景啟動器，建議加上版本，因為有些版本並沒有提供log4j配置，本博客是換回1.5.7才支持的，2.2.1的版本仲裁都沒提供對應版本的

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-log4j</artifactId>
            <version>1.3.8.RELEASE</version>
        </dependency>

ok，然後在resources直接丟log4j.properties

# LOG4J rootCategory config
log4j.rootCategory=INFO, stdout, file
# LOG4J console config
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %5p %c{1}:%L - %m%n

# root日誌輸出
log4j.appender.file=org.apache.log4j.DailyRollingFileAppender
log4j.appender.file.file=logs/springboot.log
log4j.appender.file.DatePattern='.'yyyy-MM-dd
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %5p %c{1}:%L - %m%n

啟動SpringBoot日誌：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

特斯拉需求大！住友金屬追加擴產電池材料、增至2.5倍

admin

 

日本住友金屬礦山（Sumitomo Metal Mining）28日發布新聞稿宣布，該公司雖已於去年10月27日表示將砸下180億日圓於2018年1月將鋰離子電池正極材料「鎳酸鋰（見附圖）」月產能擴增至3,550噸，不過因電動車（EV）用鋰離子電池需求擴大，因此決議對「鎳酸鋰」進行追加增產措施，計畫投入40億日圓於磯浦工廠進行增產工程，目標在2018年6月將整體「鎳酸鋰」月產能擴增至4,550噸、將達現行的2.5倍。

住友金屬礦山指出，該公司正持續擴大與Panasonic攜手研發的高性能鎳酸鋰產能，此次為了因應Panasonic擴大鋰離子電池產能、故決定對鎳酸鋰進行追加增產投資。

據日經新聞指出，住友金屬礦山追加增產「鎳酸鋰」主要是因應美國EV廠特斯拉（Tesla）增產所需。據報導，住友金屬礦山目前透過Panasonic供應特斯拉電動車所需的大部分車用電池正極材料。

根據嘉實XQ全球贏家系統報價，截至台北時間31日上午8點50分為止，住友金屬礦山上揚1.34%至1,660.5日圓，稍早最高漲至1,664.5日圓創約5個月來（2月16日以來）新高水準。

特斯拉平價電動車「Model 3」於7月28日正式交車。Business Insider、The Motley Fool、Electrek等外電報導，Model 3售價35,000美元，特斯拉原本計畫要在2020年底前，將Model 3年產量提升至50萬台，但去（2016）年該公司把目標提前兩年、移至2018年。不過，Model 3目前的生產年率還只有10萬台，特斯拉想要達標、產速勢必得快速拉升。

富士經濟6月22日公布調查報告指出，預估2030年時EV年銷售量將增至407萬台、超越HV（油電混合車、2030年銷售量預估為391萬台），且之後雙方的差距將持續擴大。富士經濟預估，在中國需求增加加持下，2035年EV全球銷售量將擴大至630萬台、將達2016年的13.4倍（較2016年增加12.4倍）。

（本文內容由授權使用。圖片出處：MoneyDJ）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

EV商機夯！Toray電池材料傳大增產、擬在美國建新廠

admin

日經新聞、日刊工業新聞1日報導，Toray計畫在2020年結束前總計砸下約1,200億日圓擴增車用鋰離子電池關鍵材料「分隔膜（separator、見附圖）」產能，目標將分隔膜年產能擴增至19.5億平方公尺、將達現行（約4億平方公尺）的約5倍。Toray目前在日本及南韓生產分隔膜，且已在南韓工廠進行增產工程，計畫在2017年度末（2018年3月底）將分隔膜年產能提高至約6.5億平方公尺。

報導指出，因法國、英國紛紛表明計畫在2040年停售汽柴油車，提振電動車（EV）有望急速普及，故Toray計畫在2019年於歐洲興建一座年產能達8,000萬平方公尺的新工廠，且除了歐洲之外，Toray也計畫在特斯拉（Tesla）等EV廠抬頭的美國興建新工廠。

特斯拉平價電動車「Model 3」於7月28日正式交車。而為了因應特斯拉增產所需，住友金屬礦山（Sumitomo Metal Mining）於7月28日宣布，將追加增產鋰離子電池正極材料「鎳酸鋰」，目標將其月產能擴增至現行的2.5倍。

鋰離子電池4大關鍵材料分別為正極材、負極材、分隔膜和電解液，而這些電池材料皆由日系廠商握有高市佔率，其中，在全球分隔膜市場上，Toray為第2大廠、僅次於旭化成（Asahi Kasei）。

日刊工業新聞6月23日報導，因車廠加快電動車（EV）的研發腳步、帶動電池材料市場成長速度超乎預期，故旭化成計畫上修鋰離子電池關鍵材料「分隔膜」的增產計畫，目標在2020年結束前將分隔膜年產能最高擴增至15億平方公尺（m2）、將達現行的2.5倍，且將遠高於原先規劃的11億m2目標，期望藉由積極投資、鞏固全球龍頭位置。預估追加擴產所需的投資額約300億日圓。

旭化成於3月30日宣布，因電動車（EV）、油電混合車（HV）等車用鋰離子電池需求預估將呈現急速增長，故決議擴增鋰離子電池關鍵材料「分隔膜」產能，計畫投下約150億日圓，在守山製造所（滋賀縣守山市）增設年產能約2億平方公尺（m2）的分隔膜產線，並預計於2019年度上半年商轉。旭化成指出，待上述增產工程完工後，該公司整體分隔膜年產能將從現行的約6.6億m2提高3成至約8.6億m2。

根據日本市調機構富士經濟（Fuji Keizai）預估，2020年全球分隔膜市場規模將增至3,000億日圓、將達2015年的2倍水準，而EV、HV等車用用途是推動分隔膜需求急增的最大功臣，預估2020年車用分隔膜佔整體市場比重將達約45%。

富士經濟6月22日公布調查報告指出，預估2030年時EV年銷售量將增至407萬台、超越HV（2030年銷售量預估為391萬台），且之後雙方的差距將持續擴大。富士經濟預估，在中國需求增加加持下，2035年EV全球銷售量將擴大至630萬台、將達2016年的13.4倍（較2016年增加12.4倍）。

（本文內容由授權使用。圖片出處：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選